[clang] [llvm] [Driver][clang-linker-wrapper] Add initial support for OpenMP offloading to generic SPIR-V (PR #120145)

Nick Sarnie via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 2 13:24:31 PST 2025


sarnex 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`.

Cool, I don't see any major issues then, just minor stuff I'll have to adapt to.

https://github.com/llvm/llvm-project/pull/120145


More information about the llvm-commits mailing list