This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [sa]: Revert partial def stuff, use fake variables instead


On Mon, 2004-12-20 at 09:27 -0500, Diego Novillo wrote:
> Zdenek Dvorak wrote:
> > Hello,
> > 
> > 
> >>>which seems terribly wrong to me.  Why should I need to change anything
> >>>so complicated, when I did not make any change that should affect
> >>>results of alias analysis?
> >>>
> >>
> >>You *have* changed the results of alias analysis.  You are introducing a 
> >>new pointer, assigning it a new address and dereferencing it.
> > 
> > 
> > and what?  I am accessing exactly the same location in memory, so from
> > the point of *results* of the alias analysis nothing changes.
> > 
> But.  you.  have.  to.  update.  your.  internal.  data.  structures.
Well, I think part of Zdenek's point is that we previously had some 
named object X and references to that object.  Now we have some pointers
to X and dereference those pointers.

Those are functionally equivalent.  In a sane world (and our aliasing
code is *FAR* from sane) the most we should have to do is tell the
aliasing code that we have a new pointer and it points to X.

Unfortunately all the nonsense with type memory tags makes that
impossible.  If you want a good laugh, look around the compiler and
see how many places have to know about type memory tag braindamage.
I was thoroughly disgusted with how many things I had to fix when
I zapped the type_mem_tag field out of the var_ann structure.

The more I work with the new code the more I'm convined that type memory
tags are just a bad bad bad idea.


> We just need a way of telling the alias system that this pointer points 
> to this location using this tag.  Even if we were to change the whole 
> aliasing representation (which may happen), we would still need to 
> update whatever data structure the new system had.
Having just run into this with ivopts with the tree-ssa-alias.c rewrite,
I can say that it's a hell of a lot easier to deal with now.  In fact,
it's trivially handled.

> This is very basic stuff.  I cannot believe we are having this discussion.
I can certainly believe we are having this discussion since I've
basically run into the same problem.


Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]