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