[PATCH] D94315: [OpenMP][FIX] Enforce a function boundary for a new data environment

Fri Jan 8 11:00:58 PST 2021

jdoerfert added a comment.

In D94315#2487259 <https://reviews.llvm.org/D94315#2487259>, @ABataev wrote:

> In D94315#2487257 <https://reviews.llvm.org/D94315#2487257>, @jdoerfert wrote:
>
>> In D94315#2487244 <https://reviews.llvm.org/D94315#2487244>, @ABataev wrote:
>>
>>> In D94315#2487242 <https://reviews.llvm.org/D94315#2487242>, @jdoerfert wrote:
>>>
>>>> I don't understand where `inaccessiblemem_or_argmemonly` is coming from. This prevents us from inlining the outlined parallel region.
>>>
>>> __kmpc_serialized_parallel and __kmpc_end_serialized_parallel functions are marked with this attribute and I think OpenMPOpt optimizes read_only functions because of this. I.e. it does not consider __kmpc_serialized_parallel and __kmpc_end_serialized_paralle function calls as opimization barriers.
>>
>> Can you provide an example why this is a problem?
>
> Looks like PR48686, you mentioned, caused by this. The second function call should not be optimized, because it is inside the region between __kmpc_serialized_parallel() and __kmpc_end_serialized_parallel() function calls.

OpenMPOpt assumes some ICVs are fixed per data environment and they are not changing within a single function. Removing `inaccessiblemem_or_argmemonly` should not make a difference here.
I'm going to propose an alternative to `__kmpc_fork_call` now, that would fix this issue as well and make a lot of things simpler and cleaner.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94315/new/

https://reviews.llvm.org/D94315