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: [PATCH][RFC] Take 2: Re-implement restrict support

On Thu, 25 Jun 2009, Daniel Berlin wrote:

> On Thu, Jun 25, 2009 at 5:36 AM, Richard Guenther<> 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.
> > (
> >
> > 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 ;)


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