[4/16] Implement -foffload-alias

On 16/12/15 14:16, Richard Biener wrote:
> 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?

Yes. An alternative could be to:
- have 'NEXT_PASS (pass_ipa_pta, true/false /* oacc_p */)' in the pass
   list,
- declare a new flag fipa-pta-oacc, and
- use fipa-pta or fipa-pta-oacc in the gate function depending on
   oacc_p.

> 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.

Committed as attached, with the following changes:
- test for opt->value of OPT_fopenacc in default_options_optimization,
   to prevent fipa-pta to be switched on by default for -fno-openacc.
- fixed pta -> pta2 scan failures.

Thanks,
- Tom

[4/16] Implement -foffload-alias

Commit Message

Patch