[Bug tree-optimization/68787] fipa-pta to interpret restrict

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68787

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 5 Apr 2016, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68787
> 
> --- Comment #5 from vries at gcc dot gnu.org ---
> Created attachment 38189
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38189&action=edit
> patch to recompute restrict info after ipa-pta
> 
> (In reply to Richard Biener from comment #4)
> > One possibility would be to re-run non-IPA PTA just to compute restrict info,
> > that is, instead of bailing out when cfun->gimple_df->ipa_pta just not update
> > SSA pointer-info but still call compute_dependence_clique.  Requires
> > splitting of compute_points_to_sets into the actual compute and SSA
> > pointer-info
> > update parts.
> 
> That sound similar to what I've tried here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01257.html .
> 
> Attaching a more minimal version.
> 
> But it doesn't affect the testcase, and I'm not sure how it could (perhaps it
> will affect another test-case, I'm not sure).
> 
> For the listed testcase, after ipa-pta we have:
> ...
> __attribute__((noclone, noinline))
> bar (intD.6 * aD.1755, intD.6 * bD.1756)
> {
>   # PT = nonlocal
>   intD.6 * a_2(D) = aD.1755;
>   # PT = nonlocal
>   intD.6 * b_4(D) = bD.1756;
>   intD.6 _6;
>   intD.6 _7;
> ...
> 
> There's nothing to take advantage of by trying to reannotate with restrict.

True.  If there's a IPA effect of restrict to be exposed it won't help.

Note that the issue with IPA PTA is that if you enable restrict tags
to be used you can end up with

static foo (int *p) { ... }
bar (int * __restrict p) { ... foo (p); /* p is restrict */  ... }
baz (int * p) { ... foo (p); /* p is not restrict */ ... }

and this breaks down having p in foo be { NONLOCAL, restrict-tag }
and the current handling making p in foo restrict (well, the current
handling can't assign cliques to functions in IPA mode, but you
see one of several issues).  Similarly recursion of bar will not
properly handle restrict I believe.

The current restrict tag handling is quite (too) conservative so
it might work in its current state only handling the 
must-point-to-restrict (or NULL) case.  You can always try ...