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:

> On Wed, Jun 4, 2008 at 4:39 AM, Richard Guenther <rguenther@suse.de> wrote:
> > On Tue, 3 Jun 2008, Daniel Berlin wrote:
> >
> >> So, the idea was to eventually remove SMT's entirely in favor of NMT's.
> >> Prior to thi, the only place we created SMT's still was for globals
> >> (that i remember).
> >>
> >> As such, your patch seems like a step backwards.
> >> Why should we bother to have SMT's anymore?
> >> There is no real reason for them in the presence of a real list of aliases.
> >> All having two types of "memory tags" did was confuse people who are
> >> used to other compilers, which simply represent a set of aliases that
> >> a symbol has.
> >>
> >> Sure, SMT's are very slightly less memory intensive.  I've yet to see
> >> a case where NMT's were so memory hungry compared to SMT"s that using
> >> SMT's was worth it.
> >
> > SMTs are not cheaper than NMTs in general, but the NMTs in the fallback
> > situation I change with the patch contain "extra" information.  For
> > example with
> >
> > int foo (int *i)
> > {
> >  return *i;
> > }
> >
> > we generate
> >
> > SMT.4, UID D.1562, int, is addressable, is global, score: 320002, direct
> > reads: 0, direct writes: 0, indirect reads: 1, indirect writes: 0, call
> > clobbered (is global var, is incoming pointer)
> >
> > NMT.5, UID D.1563, int, is addressable, is global, score: 8, direct reads:
> > 1, direct writes: 0, indirect reads: 0, indirect writes: 0, call clobbered
> > (is global var, is incoming pointer), may aliases: { SMT.4 }
> >
> > and obviously we end up just using the SMT again
> >
> >  # VUSE <SMT.4_4(D)>
> >  D.1555_2 = *i_1(D);
> >
> > I don't see the point in that.
> >
> > Now as of removing SMTs completely - I think SMTs are a sound concept.
> 
> I don't :)
> Everyone diego or I has ever tried to explain the distinction to has
> looked at us bug eyed.
> In reality, there is no difference between an SMT and an NMT (with the
> alias set stored in the mtag structure) with other NMT's as it's
> aliases.
>
> 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".

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

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.

But I don't see how the patch in question conflicts with either
approach.

Richard.