>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?
These extra opcodes (besides being less RISCy) are harder to optimize.
Instead of three integer add functions, there are five (from
include/parrot/oplib/ops.h):
PARROT_OP_add_i_i, /* 38 */
PARROT_OP_add_i_i_i, /* 39 */
PARROT_OP_add_i_i_ic, /* 40 */
PARROT_OP_add_i_ic, /* 41 */
PARROT_OP_add_i_ic_i, /* 42 */
This makes it hard to, for example, do constant propagation. If I
have the code:
set I0, 42
add I1, I0, 1
it is simple to propagate the constant 42 to eliminate the first
function and do constant folding on the second. But if I have:
set I0, 42
add I0, 1
the propagation function will have to be smarter than it should have
to be to correctly optimize this code.
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. 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". Conversion to more optimized
opcodes is a type of peephole optimization that should be done at the
very end of the optimization phase.
Just my thoughts,
-Curtis
