[PATCH] D88978: [WIP] Attach debug intrinsics to allocas, and use correct address space

Alexey Bataev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 21 03:46:08 PDT 2020


ABataev added a comment.

In D88978#2343484 <https://reviews.llvm.org/D88978#2343484>, @jdoerfert wrote:

> I have no idea what from the commit message what this has to do with the OpenMP code gen but I saw this randomly while looking for something else so here we go:
>
> In D88978#2326036 <https://reviews.llvm.org/D88978#2326036>, @scott.linder wrote:
>
>> In D88978#2325991 <https://reviews.llvm.org/D88978#2325991>, @ABataev wrote:
>>
>>> In D88978#2325982 <https://reviews.llvm.org/D88978#2325982>, @scott.linder wrote:
>>>
>>>> @ABataev Sorry if I'm pulling you in without enough context/work on my end, but I wanted to ask how the Clang codegen for OpenMP locals works at a high level?
>>>>
>>>> Is the idea that instead of an `alloc` the frontend can insert calls into the runtime in some cases, like `__kmpc_alloc` (e.g. for `firstprivate` as in https://reviews.llvm.org/D5140)?
>>>
>>> Yes, right.
>
> The frontend does *not* insert `__kmpc_alloc` calls for `firstprivate`, or almost anything else for that matter. Grep `clang/lib` and you can find 2 uses, both in very specialized cases not related to "regular" user allocations". `alloca` is used as with basically everything else: https://clang.godbolt.org/z/z8fEqG

They are inserted for pragma allocate and privates with allocate clauses.

>>>> If that is the case, I assume there is no equivalent to SROA/Mem2Reg here?
>>>
>>> I assume, no.
>>>
>>>> I am trying to understand conceptually where the debug info for the source level local should be tied to in the IR, and at least for locals which use `alloc` it has turned out to be much simpler to tie the variable directly to the `alloc` itself rather than bitcasts and things which obscure the relationship.
>>
>> Ok, thank you! I think the simplest thing is for me to update the patch to tie the debug info to the call to the runtime allocator, then.
>
> SROA/mem2reg is happening as you expect it to. FWIW, we also have heap2stack and argument-promotion + constant prop for parallel regions implemented in the Attributor. That means we would/will apply SROA/mem2reg even if you have a runtime alloca and if the value is nominally "shared" but could be made firtprivate.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88978



More information about the cfe-commits mailing list