On Sat, 2005-08-20 at 19:15 -0700, Richard Henderson wrote:
> On Fri, Aug 19, 2005 at 09:34:35PM -0400, Daniel Berlin wrote:
> > But for general IPA working on the cgraph + GIMPLE level, as is what is
> > happening here, I think we really need to do something about static
> > variable initializers so they are in GIMPLE.
>
> No. How could that possibly be?
> We can't execute code for static
> variable initializers, so how can we gimplify?
What do you mean by this, exactly?
>
> > Or do you have another idea?
>
> You didn't say why analyze_expr was wrong. I still think it's right.
Because analyze_expr doesn't give us any of the info we want.
The call that was failing in our case was a get_base_var of an
ADDR_EXPR<CONSTRUCTOR> in a static variable initial, called from static
variable address taken analysis.
analyze_expr would not help here.
The docs for analyze_expr says:
This function is responsible for lowering tree nodes not
understood by
generic code into understandable ones or alternatively marking
callgraph and varpool nodes referenced by the as needed.
It's the "alternatively" part that makes it useless.
cxx_callgraph_analyze_expr, an implementation of this hook, simply marks
a bunch of varpool nodes as "used" (and it doesn't even tell us which
ones).
We don't care to know whether or not it should be marked used.
We want to know what's actually in the trees on the initializer them so
we can do analysis.
IE if we have something very funky like:
static int c;
static int d;
static struct foo *a = &{&c, &d};
(and if you look, andrew found a case where we are producing
&<constructor>, so this is a possibility, AFAICT)
In the above case, we need to see the &c, &d part.
How does analyze_expr help us here?
>
> r~
