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