This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[tree-ssa] RFC: Dropping INDIRECT_REF variables
- From: Diego Novillo <dnovillo at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 14 May 2003 11:09:17 -0400
- Subject: [tree-ssa] RFC: Dropping INDIRECT_REF variables
- Organization: Red Hat Canada
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.
- 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?
Diego.