On Jul 20, 2005, at 9:01, Curtis Rawls wrote:
From working with the optimizer, I have some questions about the PASM
opcodes, in particular the "inout" opcodes. For example, adding
integer registers is defined by the "add(out INT, in INT, in INT)".
But if one of the input registers is also the output register, it can
be simplified to "add(inout INT, in INT)". And additionally, if the
other integer is a constant of value 1, it can be further reduced to
"inc(inout INT)". My question is: Is there an advantage in having
these additional opcodes?
Shorter byecode size, a possibly faster representation in the JT
runcore.
This makes it hard to, for example, do constant propagation. ...
So, I would like to know if the runtime handles these "inout"
shorthand opcodes differently than the regular codes. If not, I would
encourage the team to removed them.
Removing these opcodes isn't and option, now. But ...
... Also, I suggest that all opcodes
coming into the optimizer should be of the highest possible form, ie
"inc I0" should be "add I0, I0, 1".
... as these optimizations are typically most effective with code
generated by compilers, it's probably simplest to add a paragraph to
docs/compiler_faq.pod, which opcodes should be generated.
Conversion to more optimized
opcodes is a type of peephole optimization that should be done at the
very end of the optimization phase.
Yep.
Just my thoughts,
-Curtis
leo
