Re: [PATCH] Do not create NMTs for pt_anything pointers

[Richard Guenther <rguenther at suse dot de>]

On Wed, 4 Jun 2008, Daniel Berlin wrote:

> >> So why maintain the aritificial distinction, which people generally
> >> find confusing?
> >
> > Uh, ok - the distinction is artificial on the implementation level,
> > but not on the semantics level IMHO.  We _need_ some tags that
> > represent conflicts between memory based on type-based aliasing rules.
> > Just because not all memory has proper "names".
> >
> 
> Okay, then we should at least rename them. Nobod knows what the heck a
> "symbol memory tag" is. Didn't the used to be TMT's?

Yeah, the naming is arbitrary and confusing.  TMT (type memory tag)
was actually more to the point ;)

> > But we don't really need name-memory tags, as if we have points-to
> > information (that is more specific than pt_anything), then we already
> > _do_ have "names" that we use for representing the conflicts.
> 
> Sure
> 
> >
> >> I'm willing to believe we should maintain the fallback (mainly because
> >> i haven't had time to test a patch to just have alias bitmaps for
> >> everything, even without PTA), but there is no need for that fallback
> >> to rely on a completely different structure and name when it would
> >> work fine with the same one we use in the presence of PTA.
> >
> > We _do_ have alias bitmaps for everything!  We just store them in
> > two (ok, actually three) different places.  The point is that I guess
> > neither you nor I want to audit all passes that create new pointers
> > to properly set the points-to bitmap in its ptr_info.
> 
> Right.
> :)

;)

I'll put it somewhere on my TODO list ...

> >
> > If we would do that we can get rid of either the name SMT or NMT but
> > at least its MTAG_ALIASES bitmap (and instead use the shared GC-allocated
> > ones we hang off the ptr_info struct).  We still need to create tags
> > for the type-based conflicts and generate their conflict bitmaps - but
> > we can store them in the pt_vars of ptr_info instead of accessing them
> > via the symbol_memory_tag in var_ann.
> Sure.
> 
> 
> > But I don't see how the patch in question conflicts with either
> > approach.
> 
> Okay, I withdraw my objection.
> Feel free to commit it

Thanks.  The main motivation was to delete some code and save some
memory at the same time.

Richard.