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