Re: [tree-ssa] Out of SSA status and issues

[Daniel Berlin <dberlin@dberlin.org>]

On Tuesday, May 13, 2003, at 08:56  AM, Michael Matz wrote:

> Hi,
>
> On 13 May 2003, Diego Novillo wrote:
>
>> Why?
>>
>>      1. foo()
>>      2. {
>>      3.   int i, *p;
>>      4.
>>      5.   p = malloc();
>>      6.   i = *p;
>>      7.   return i + 9;
>>      8. }
>>
>> I see nothing wrong in replacing 'i + 9' with '*p + 9'.
>
> I do.  *p could have been changed in between 6 and 7.  The useful 
> thing of
> SSA is, that there is exactly one definition of an entity, and that is 
> the
> reason that you can copy-propagate extremely easily (because you know,
> that the source of the copy can't be possibly changed after that copy
> insn, because the def must have reached it, and that was the only def).
>
> To be able to propagate *p you have to explicitely proove by some means
> that it still is unchanged at the places of the uses of the copied-into
> entity.  This would be exactly detrimental to the usefullness of copy
> propagation.
>
> I.e. *p is not a register but an expression, and a copy instruction 
> copies
> registers to registers.
>

It would also ruin sparse register promotion that load PRE will do 
soon, by unpromoting things.

>> Not that tree-ssa will do anything with this code, the default
>> type-based aliasing is too conservative, but PTA may disambiguate 
>> this.
>
> Of course you _can_ optimize such cases, but it's not a subset of copy
> propagation but, hmm, un-PRE or something like that.
>

It's SSUSPRE (Static Single Use Store PRE).
Store PRE builds a single static use form, ...

>
> Ciao,
> Michael.
>