Nicholas Clark wrote: > 1: the value in the register did/didn't change > 2: the value of the thing referenced by the register did/didn't change > > (possibly 2a and 2b being that the internals of the object didn't/might've > changed)
Actually, thinking now of an optimizer, we should know these things. given the instruction: set P0, P1[1000] and this is the last instruction in the life cycle of P0, this instruction could be deleted. But when reading the array had the side effect of extending this array, it gives different results when you get the array size, depending on -Ox. > So then JITs, imcc and other things would know the difference between what > these two do > > add inout_val P1, in P2, in P3 > > set out_reg P1, in P2 Above are no problem, but here is another one, "out_reg" is not enough: set out_alias P1, in P2 new out_reg P1, inconst I0 The former is currently handled by propagate_alias() in imcc. The latter is a typical instruction, which ends the life cycle of an old P1 and starts a new one, so that the register allocator could and does reuse this very parrot register. > Nicholas Clark leo