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



Reply via email to