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