This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa]: PRE updates
On Wed, 2003-06-11 at 09:49, Diego Novillo wrote:
> On Wed, 2003-06-11 at 09:27, Andrew MacLeod wrote:
> > SO the code you are looking at above created thge a_5 PHI stmt... Its
> > a_5 I am creating the var_ann for, because I just created it out of thin
> > air.
> But wait, var_ann(a_5) *must* be the same as var_ann(a_4) which is
> var_ann(a). SSA_NAMEs do not have annotations, their associated
> VAR_DECLs do. So, if you are only creating a new SSA_NAME for a
> VAR_DECL that has been referenced already, then that VAR_DECL should
> already have an annotation.
> So, I still wonder why VAR_DECL 'a' didn't have an annotation. It
Maybe it did, I didnt try dan's test case, just looked at the line
numbner and the line number in my file, and said 'ah ha'. So maybe its
something else. we'll have to actually look closer.
Dan, whats the line in your source code that is failing, and if its in
that hunk, whats the PHi node? the one I just created?
> Hmm, create_var_ann() shouldn't allow creating annotations on
> SSA_NAMEs. We may want to change that, but in the current
> implementation the above is wrong: var_ann (PHI_RESULT (phi)) will never
> access the annotation you just created. The first thing var_ann() does
> is peel the SSA_NAME wrapper to get at the VAR_DECL.
OK, I was giving it to dan to try, maybe it would have died.
> Which brings me to the real issue. Is it the case that we want to have
> annotations on SSA_NAMEs instead of the _DECLs that they wrap? That is
> a non-trivial change because var_ann_d describes attributes for
> VAR_DECLs. Those attributes are shared by all the SSA_NAMEs created for
> that _DECL.
Well, how does that has_real_ref work then? that means *all* ssa_names
of a particular variable which occur in PHI nodes is going to be in the
list for the coalescer even if only one of them is actually referenced?
thats doesn't seem right.