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.