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 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

>   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.

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

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.

But what's most interesting about this organization is that we can
greatly reduce our reliance upon TBAA, which is a huge compile-time

> 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

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