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 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.
Otherwise, it sounds like you are just describing an explicit points-to
graph.

> Similarly if you read an aliased variable by name, you have a single
> VUSE for that variable's tag.  If you write that variable, then you
> have a V_MAY_DEF for that variable's tag, it's ancestors and its
> children.
> 
> We end up with a lot fewer VUSEs and more VDEFs.  We can (and should)
> be able to do a much better job at grouping without affecting
> optimization opportunities.

Certainly we can create sets much better than we do now, and have a
parent-child relationship between sets.
However, we have to be very careful to make sure these sets don't
contain unnecessary entries and links, which is hard to do.

> 
> > 
> > It seems like all you are suggesting is the equivalent just removing the
> > alias list from the name tags, and including the name tag uids on the
> > pt_vars of the ptr_info.
> > 
> > IE name tags just become placeholders.
> Yup.  The difference between what Zdenek is proposing and what I've been
> doing isn't all that different -- a tag is just a representative 
> placeholder for a hunk of memory.  I just add the parent/child
> relationships.



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