[PATCH] D141105: [OpenMP] Add support for '--offload-arch=native' to OpenMP offloading
Joseph Huber via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Jan 6 05:28:37 PST 2023
jhuber6 added a comment.
In D141105#4031103 <https://reviews.llvm.org/D141105#4031103>, @JonChesterfield wrote:
> Possible naming hazard here. march=native means target the local processor architecture, zen2 or whatever, and we have the host CPU as an offloading target already. So what I'd expect this to do is host offloading with the openmp runtime compiled for the local variant of x86 or aarch64, not for it to have a guess at a GPU target.
>
> What you think of offload-arch=GPU for pick a plausible GPU? That distinguishes it from other things we might want to offload to. Open question whether it should create a vgpu instance if it can't detect a physical card.
There is some prior art here, e.g. CUDA <https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/#options-for-steering-gpu-code-generation> and CMake <https://cmake.org/cmake/help/latest/prop_tgt/CUDA_ARCHITECTURES.html>, but we don't necessarily need to follow them. I'm in favor of `native` because it tracks with what the user "expects" `native` to do. It may be somewhat ambiguous given that we can offload to the host, but I think native in the future should just go with whatever we can detect no the user's system. So if someone has some future FPGA it'll detect that. We can still use `native` in the host way with this syntax, we just can't infer the triple. e.g. `clang foo.c -fopenmp -fopenmp-targets=x86_64-unknown-linux-gnu --offload-arch=native` will do what you except.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D141105/new/
https://reviews.llvm.org/D141105
More information about the cfe-commits
mailing list