This is the mail archive of the 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 Thu, 2004-12-23 at 13:33 -0500, Daniel Berlin wrote:
> On Thu, 2004-12-23 at 10:46 -0700, Jeffrey A Law wrote:
> > On Thu, 2004-12-23 at 11:40 -0500, Daniel Berlin wrote:
> > > > You need to put something to virtual operands; I just need some
> > > > representant for the newly created group.
> > > 
> > > Yes, i know, that's what name tags really are when we do grouping.
> > > They are just representatives.
> > Precisely.  They're also a convenient way to represent unnamed storage
> > areas (ie, malloc'd memory).  But basically their primary use is for
> > grouping.
> > 
> > >   They just happen to also have the alias
> > > list with them instead of storing it in pt_vars.
> > One of the interesting things I'm playing with is _not_ having the alias
> > list or pt_vars.  Instead we organize tags as a tree.  The root is all
> > of memory, the leafs are typically scalars in memory.
> > 
> > Given a pointer P, if we read P, then we have a single VUSE for whatever
> > tag is associated with P.  If we write P, then we have a V_MAY_DEF for
> > P, P's ancestors and P's children.
> Why the ancestors?  
> A store to P can only affect P and what P points to, not what points to
> P.

So let's say I have two pointers P & Q.  I know P points to variable V
in the stack and Q points to anything.

x = *q;
*p = whatever
y = *q;

If we don't show that the second statement affects all of memory, then
we would commonize the two loads from *q.

Maybe you're confused what about what I mean by ancestor - ancestors in
the tree refer to containing memory regions.

So given

struct x
  int i;
  float f;

If we allocated such a structure on the stack, then we'd have a tree

    stack memory
    struct x x;
       /  \
  field i field f

[ Where field i and field f would only exist if we had something like
  p = &x.f and q = &x.i and we dereferenced p & q. ]

> However, we have to be very careful to make sure these sets don't
> contain unnecessary entries and links, which is hard to do.
Most definitely.   One of the interesting aspects of organizing our
aliasing information this way is how we do grouping because a
store through a points-to-anything pointer is, err, expensive.

In fact, if there was one thing that worries the crap out of me, it's
the cost of storing through a points-to-anything variable.  That cost
will likely mean that we'll have to always do grouping.  The trick
is to group intelligently :-)


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