[tree-ssa]: Dominator opts change LHS without changing VDEF's
Diego Novillo
dnovillo@redhat.com
Sun Aug 10 23:56:00 GMT 2003
On Sun, 2003-08-10 at 17:41, Daniel Berlin wrote:
> On Sun, 10 Aug 2003, Diego Novillo wrote:
>
> > On Sun, 2003-08-10 at 17:31, Daniel Berlin wrote:
> >
> > > > bitmap_element_free (struct bitmap_element *elt)
> > > > {
> > > > ....
> > > > {
> > > > struct bitmap_element * elt;
> > > > struct bitmap_head_def * head;
> > > >
> > > > head = head;
> > > > elt = elt; <-- Here 'elt' points to 'elt'.
> > >
> > > No, this statement means elt (lhs) points to whatever elt (rhs) points to.
> > > elt doesn't point to elt.
> > >
> > Ah, yes. I see the distinction now. To fix this, you need to change
> > the query we do in tree-dfa.c:get_memory_tag_for. Currently, we only
> > ask whether the pointer may point to the variable. Is there a query
> > that we can do to ask 'whether this pointer points to the same memory
> > pointed by this other pointer?'. That's the query we are missing.
> >
> > Both LHS elt and RHS elt *must* have the same memory tag.
>
> I'm curious why. The copy propagation was perfectly valid, and should
> have been performed, actually.
>
Right, the copy propagation was perfectly valid. What happened is that
when the statement was re-scanned for operands after copy-propagation,
the new pointer introduced a different memory tag which wasn't there
before and for which we didn't have SSA information.
Memory tags represent the memory pointed-to by a pointer. If two
pointers may point to the same memory location, then it is only natural
that they should have the same memory tag. This equivalence of memory
tags is not only useful to reduce the number of symbols. It prevents
calls to the SSA renamer when new symbols are introduced in virtual
operands.
That's why if two pointers may point to the same memory location, they
should receive the same memory tag.
Diego.
More information about the Gcc
mailing list