jdoerfert added a comment. 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 >>> 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