[llvm-branch-commits] [flang] [mlir] [Flang][OpenMP] Add pass to replace allocas with device shared memory (PR #161863)
Michael Kruse via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Thu Feb 26 04:18:00 PST 2026
https://github.com/Meinersbur commented:
> Similarly, any random dialect's op lowering to `llvm.alloca` would end up having to be patched too, and doing context-dependent `llvm.alloca` translation to OpenMP device shared memory APIs I think we all agree would be entirely out of the question, since we don't want to add a dependency to OpenMP to the LLVM dialect. There's nothing we could do at the OpenMPToLLVMIRTranslation stage, since that can only deal with `omp` dialect operations and discardable attributes there.
Makes sense. Invoking the pass later before lowering is a good idea.
One question though: How do we know that the semantics of a particular `llvm.alloca` is meant to be shared memory? This PR is inferring it from its uses, but this doesn't necessarily mean oit is the intition. For instace, the PR has exceptions for `private_syms`, but how dow we know there are no other exceptions?
> > To be usable in indirectably reached regions, the adress mlir::Value has to be passed to it in either case, why is it relevant?
>
> Unfortunately, I don't think I quite understand this concern. Could you elaborate on it?
It's been some time ago, but I think I meant something like this:
```c
void foobar(void *x) {
// access *x
}
#pragma omp target private(x) {
{
#pragma omp teams {
foobar(&x);
}
}
```
`foobar` (the "indirectably reached region") could not access the shared_alloca `x` without having it passed as a pointer as an argument. And `foobar` does not need to know where the memory comes from. It was referring to the second paragraph of the .td doc of StackToShared.
https://github.com/llvm/llvm-project/pull/161863
More information about the llvm-branch-commits
mailing list