This is the mail archive of the
mailing list for the GCC project.
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<firstname.lastname@example.org> 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.
int * restrict 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 ;)