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
