Re: [tree-ssa] RFC: Dropping INDIRECT_REF variables

[Andrew MacLeod <amacleod@redhat.com>]

On Wed, 2003-05-14 at 11:09, Diego Novillo wrote:

> - The SSA->normal pass may also need to handle INDIRECT_REF
>   variables with care.  Since an INDIRECT_REF variable has two
>   SSA versions in it, overlapping live ranges of the base pointer
>   or the INDIRECT_REF node may need extra supporting code (this
>   is just a vague concern, Andrew?).
> 

The SSA->Normal pass is in the process of ignoring INDIRECT_REF
variables anyway, but it does have to handle them when they occur as
real operands..

  ie
    T.14 = (*p_5)_8

needs to be recognized by the SSA->normal translator, and converted to
    T.14 = *p_5

So it requires a bunch of special casing during building, analyzing/ and
translation out.  Having them go away or at least never be a part of a
real operands is the way to go.


> - We disable the ability to treat non-aliased pointer
>   dereferences as if they were variables.  We would lose the
>   ability to do some optimizations like:
> 
>   foo ()                                 foo ()
>   {                                      {
>     char[7] * T.1;                          char[7] * T.1;
>     char T.2;                               char T.2;
>     char * s;                               char * s;
> 
>     T.1 = "string";                     |   return (int)100;
>     s = (char *)T.1;                    <
>     *s = 100;                           <
>     T.2 = *s;                           <
>     return (int)T.2;                    <
>   }                                      }
> 
>   I can live with this loss.  I cannot say for sure if this is
>   going to be a real problem because I still haven't implemented
>   the change.  If it turns out to be a huge loss, then we should
>   either reconsider or think of alternatives.
> 

All you were doing were taking unaliased dereferences, and replacing
them with a variable. It was basically a simple expression replacement
based on a single simple case... a dereference of a memory location that
wasn't alasied with anything. 

I find it hard to beleive that this isn't going to be caught by some
other optimization that handles expressions and looks at loads and
stores.

Andrew