[PATCH][RFC] Take 2: Re-implement restrict support

[Richard Guenther]

On Thu, 25 Jun 2009, Daniel Berlin wrote:

> On Thu, Jun 25, 2009 at 5:36 AM, Richard Guenther<rguenther@suse.de> wrote:
> >
> > On top of the patch to rip out the old restrict implementation this
> > is take 2 in re-implementing restrict support to be integrated with
> > PTA and the alias-oracle.
> > (http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01885.html)
> >
> > Compared to the first try this does not apply filtering of NONLOCAL
> > or ANYTHING but instead defers everything to the alias-oracle which
> > queries restrict information (which is still encoded in the points-to
> > bitmap) using the new pt_solutions_same_restrict_base from the
> > ptr_derefs_may_alias_p disambiguator.
> >
> > The main features remain the same. Â We use the points-to analysis
> > propagator to compute the 'based on' property, encoding it in
> > restrict tags pointed to. Â Sources of restrict tags include
> > struct fields and the implementation should be more forgiving to
> > not 100% standard conforming code (see the testcase added by
> > the patch removing the old implementation, PR38212). Â The new
> > implementation also handles merging two restrict pointers
> > correctly, so restrict1 can be disambiguated against
> > flag ? restrict2 : restrict3 which was not possible before.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu without any
> > regressions / false progressions this time.
> >
> > Comments? Â I'd like to get an ack on this (and the removal of
> > the old implementation), even though I can technically approve
> > the patch myself.
> 
> This looks good to me.  The only thing I see is that it looks like you
> can end up with RESTRICT variables in the points-to sets of
> non-restricted variables if you try hard enough.

Yes, you even don't need to try that hard.  It wastes some bits,
but that should be all.

> I guess you can't avoid this though, since people will always do
> illegal things :)

Heh, that of course as well.

> > + Â  /* For global vars we need to add a heapvar to the list of referenced
> > + Â  Â  Â vars of a different function than it was created for originally. Â */
> > + Â  if (gimple_referenced_vars (cfun))
> > + Â  Â  add_referenced_var (heapvar);
> 
> I'm not sure what this comment is trying to say, since it doesn't
> match what the code is doing (unless there is a push cfun somewhere
> before calling this).  I assume this is for IPA PTA or something.

It's for

int * restrict p;

int foo(void)
{
  return *p;
}

int bar(void)
{
  return *p;
}

where as we have the global hashtable mapping from 'p' to its
heap variable 'RESTRICT' we create the tag during PTA of foo
and re-find the tag during processing of bar.  So we have
to make sure it is in its referenced vars bitmap as well.

You could call this IPA-PTA ;)

Richard.