[tree-ssa] RFC: Dropping INDIRECT_REF variables

[Daniel Berlin]

On Wednesday, May 14, 2003, at 11:09  AM, Diego Novillo wrote:

> Supporting INDIRECT_REF variables in the base framework is
> getting to be increasingly annoying.  We have to handle several
> corner cases and need additional support code that increases the
> complexity of the implementation without giving us many benefits.
>
> - To properly deal with INDIRECT_REF variables, we need to use
>   shared tree nodes.  All the optimization and analysis passes
>   rely on pointer equality for testing if two variables are the
>   same.
>
> - Sharing expressions is always a problem, particularly with
>   passes like mudflap that need to instrument them.  Also, to
>   properly support INDIRECT_REF variables we now need to rewrite
>   both the INDIRECT_REF node (*P) and its base pointer (P).  This
>   means that we have to selectively unshare INDIRECT_REF nodes.
>   Not particularly hard, but brittle and annoying to maintain.
>
> - More often than not, INDIRECT_REF variables represent aliased
>   loads and stores.  This means that we don't really do anything
>   interesting with them in the optimizers.  We just use them for
>   liveness and alias analysis.
>
> - 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?).
>
>
> What I'm planning to do is stop renaming INDIRECT_REF nodes as if
> they were variables.  This means that INDIRECT_REF nodes need not
> be shared anymore and are treated as any other expression.  I'm
> trying to think about the ramifications of this change.  So far:
>
> - A whole chunk of code in the SSA/DFA passes would disappear.
>   This can only be good.
>
> - 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.
>
> - Since INDIRECT_REF are unary expressions, they should probably
>   be better handled by SSAPRE.  Daniel, do you think this is
>   feasible?  The whole idea of SSAPRE is building an SSA web for
>   expressions, so it seems to me that this would be a perfect fit
>   for it.

As long as the alias/pta info remains, i can do it there.
I just need to be able to tell aliasing relationships accurately so 
that i can determine when a store happens that may affect our load.
We also end up transforming the loads into temporaries through register 
promotion, so further passes only need to optimize the variables we've 
temp stored them in.

>
> - The type-based alias analysis pass needs to be modified to stop
>   relying on INDIRECT_REF variables.  This should not be too
>   hard.  We need to change it to keep track of indirect loads and
>   stores.  The partial change I have is implementing that.
>
>
> Thoughts?
>

We can always revisit this decision later if necessary, right?
It's not like we are making it impossible somehow for it to be 
implemented later, it's just something we aren't going to deal with at 
the moment.

>
> Diego.