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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
