This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]