On Mon, 14 Dec 2015, Tom de Vries wrote: > On 14/12/15 14:26, Richard Biener wrote: > > 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? > > Done. But using a clone means using the same gate function, and that means > that this pass_ipa_pta instance no longer runs by default for openacc by > default. > > I've added enabling-by-default of fipa-pta for fopenacc in > default_options_optimization to fix that.
Hmm, but that enables both IPA PTA passes then? I suppose that's ok, and if not enabling the "late" IPA PTA you'd want to re-set gimple_df->ipa_pta. > > sub-passes of IPA passes can > > be both ipa passes and non-ipa passes. > > Right. It does mean that I need yet another pass (pass_ipa_oacc_kernels) to do > the IPA/non-IPA transition at pass/sub-pass boundary: > ... > NEXT_PASS (pass_ipa_oacc); > PUSH_INSERT_PASSES_WITHIN (pass_ipa_oacc) > NEXT_PASS (pass_ipa_pta); > NEXT_PASS (pass_ipa_oacc_kernels); > PUSH_INSERT_PASSES_WITHIN (pass_ipa_oacc_kernels) > /* out-of-ipa */ > NEXT_PASS (pass_oacc_kernels); > PUSH_INSERT_PASSES_WITHIN (pass_oacc_kernels) > ... > > OK for stage3 if bootstrap and reg-test succeeds? Ok. Richard.
