The OpenMP offloading libraries are built with fixed triples and linked
in during compile time. This would cause un-helpful errors if the user
passed in the wrong expansion of the triple used for the bitcode
library. because we only support these triples for OpenMP offloading we
can normalize them to the full verion used in the bitcode library.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Wrong fix. The user typing -fopenmp-targets=amdgcn is an error, we shouldn't swallow errors here and hope the backend does something sane with the result. We should rewrite that in clang to the right triple.
This may 'work', if the correct triple is the one which wins the conflict, provided nothing triple-dependent has already happened in the IR, and we never target another OS, but that's much less robust than setting the HSA triple directly.
llvm/lib/Linker/IRMover.cpp | ||
---|---|---|
1482 ↗ | (On Diff #401252) | I'm a bit disturbed the linker is special casing bitcode file names |
Comment Actions
LG, thanks!
clang/lib/Driver/Driver.cpp | ||
---|---|---|
778 | Might be worth mentioning in the comment that this is essentially a user convenience feature. We're not so much normalising, as treating fopenmp-target=nvtpx64 as an abbreviation for nvptx64-nvidia-cuda |
Might be worth mentioning in the comment that this is essentially a user convenience feature. We're not so much normalising, as treating fopenmp-target=nvtpx64 as an abbreviation for nvptx64-nvidia-cuda