[clang] [llvm] [Driver][clang-linker-wrapper] Add initial support for OpenMP offloading to generic SPIR-V (PR #120145)
Joseph Huber via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 2 13:22:03 PST 2025
jhuber6 wrote:
> > Sure, what's left for this to work? I'm probably going to be messing around with the OpenMP 'DeviceRTL' more, likely killing off the 'fatbinary' and just using the per-target runtime dir stuff. I'm going to assume this wouldn't work well with SPIR-V since they don't have a consistent toolchain set up yet. What's we'd need is something like this.
>
> If you mean the entire flow, first we need some work in the OMP FE to generate valid OMP SPIR-V (some of the stuff we do in DeviceRTL with specifying the addressspaces explicitly on globals make the OMP FE generate bad IR because it never had to deal with SPIR-V's weird global var addressspace /addrspacecast rules before)
>
> But assuming that works, then yeah we will have to figure out how we want to generate DeviceRTL. I'm not too familiar with the per-target dir stuff, but if the problem is we will have a single RTL for all SPIR-V arches but there will be multiple vendors so the triple won't lead us to the right directory since we only generated one RTL archive for all SPIR-V, then yeah we'll need something special but it should be doable. If I completely whiffed what you were talking about let me know.
>
> After that we need the actual runtime plugin (at least for Intel devices), which we are working on but it's big.
The vendor should be part of the triple, so realistically we'd have `spirv64-unknown-amd` or `spirv64-unknown-intel`.
https://github.com/llvm/llvm-project/pull/120145
More information about the llvm-commits
mailing list