On Sun, 13 Dec 2015, Tom de Vries wrote: > On 11/12/15 14:00, Richard Biener wrote: > > 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. > > > > > I've tried this approach, but realized that this changes the order in which > non-openacc functions are processed in the compiler, so I've abandoned this > idea. > > > > 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. > > > > This patch: > - moves the kernels pass group to the first position in the pass list > after ealias where we're back in ipa mode > - inserts an new ipa pass to contain the gimple pass group called > pass_oacc_ipa > - inserts a version of ipa-pta before the pass group.
In principle I like this a lot, but + NEXT_PASS (pass_ipa_pta_oacc_kernels); + NEXT_PASS (pass_oacc_ipa); + PUSH_INSERT_PASSES_WITHIN (pass_oacc_ipa) I think you can put pass_ipa_pta_oacc_kernels into the pass_oacc_ipa group and thus just "clone" ipa_pta? sub-passes of IPA passes can be both ipa passes and non-ipa passes. Thanks, Richard.
