Dan Sugalski (via RT) wrote: > We need to nail down what the directions mean.
This is, what I'm trying to do since quite a time. > ... The IMCC and JIT folks > are the ones that care here. Here is the IMCC folks speaking ;-) >... I've been working on the assumption that > an out means that the register in question may change value, so it's > not appropriate on, say, add P1, P2, P3, since the destination > *register* doesn't change, just the value of the PMC in the register. This is what I did say in my first attempt to clarify this, my proposal then was, to make them all »in«. Then Angel Faus answered, that »inout« would be more appropriate, because something in this PMC is modified. This is ok for me, because »inout« is for the life cycle of a register the same as »in«, so I treat »inout« as »in«. With my patch we would have in ... I,S,N,P unchanged inout..I,S,N new value, P unchanged, but some change inside out... I,S,N,P new value ... which is ok, as long as we don't have an op like: make_me_an_arr(inout PerlHash) which would make a different PMC out of it's argument (I mean not by changing the vtable, but return a new PMC) Actually a »in« argument is always ok, because it means for IMCC, this register is alive. A »out« means, for the register allocator, we have a new value, so don't care about the old value, this can be assigned the same "physical" parrot register. So too much »in« ARGDIRS just provoke a worse register allocation and maybe spilling. leo
