[PATCH, 4/16] Implement -foffload-alias

[Richard Biener]

On Fri, 11 Dec 2015, Tom de Vries wrote:

> On 13/11/15 12:39, Jakub Jelinek wrote:
> > We simply have some compiler internal interface between the caller and
> > callee of the outlined regions, each interface in between those has
> > its own structure type used to communicate the info;
> > we can attach attributes on the fields, or some flags to indicate some
> > properties interesting from aliasing POV.  We don't really need to perform
> > full IPA-PTA, perhaps it would be enough to a) record somewhere in cgraph
> > the relationship in between such callers and callees (for offloading regions
> > we already have "omp target entrypoint" attribute on the callee and a
> > singler caller), tell LTO if possible not to split those into different
> > partitions if easily possible, and then just for these pairs perform
> > aliasing/points-to analysis in the caller and the result record using
> > cliques/special attributes/whatever to the callee side, so that the callee
> > (outlined OpenMP/OpenACC/Cilk+ region) can then improve its alias analysis.
> 
> Hi,
> 
> This work-in-progress patch allows me to use IPA PTA information in the
> kernels pass group.
> 
> Since:
> -  I'm running IPA PTA before ealias, and IPA PTA does not interpret
>    restrict, and
> - compute_may_alias doesn't run if IPA PTA information is present
> I needed to convince ealias to do the restrict clique/base annotation.
> 
> It would be more logical to fit IPA PTA after ealias, but one is an IPA pass,
> the other a regular one-function pass, so I would have to split the containing
> pass groups pass_all_early_optimizations and pass_local_optimization_passes.
> I'll give that a try now.
> 
> Any comments?

I don't think you want to run IPA PTA before early
optimizations, it (and ealias) rely on some initial cleanup to
do anything meaningful with well-spent ressources.

The local PTA "hack" also looks more like a waste of resources, but well 
... teaching IPA PTA to honor restrict might be an impossible task
though I didn't think much about it other than handling it only for
nonlocal_p functions (for others we should see all incoming args
if IPA PTA works optimally).  The restrict tags will leak all over
the place of course and in the end no meaningful cliques may remain.

Richard.