On Fri, Jul 17, 2015 at 1:01 PM, Artem Belevich <t...@google.com> wrote:
> > > + if (const CudaDeviceAction *CDA = >> dyn_cast<CudaDeviceAction>(A)) { >> > > + // Figure out which NVPTX triple to use for device-side >> compilation >> > based on >> > > + // whether host is 64-bit. >> > > + llvm::Triple DeviceTriple(C.getDefaultToolChain().getTriple >> > ().isArch64Bit() >> > > + ? "nvptx64-nvidia-cuda" >> > > + : "nvptx-nvidia-cuda"); >> > >> > It seems like a pretty bad layering violation to need to know these >> > particular triples right here... >> > >> > Well, it's up to driver to figure out device-side triple. While I agree >> that >> > it's way too much target knowledge for the driver, I'm short on >> practical >> > ideas. Do you have any suggestions? >> >> I guess I might expect this to be figured out in buildCudaActions, near >> where we figure out the device architectures. I guess this triple is >> more based on the host-side target though? >> > > Device triple is assumed to be a variant of NVPTX matching 32/64-bitness > of the host. > I guess I can compute the triple and stash it in CudaDeviceAction along > with GPU arch. > > >> >> This is already a little bit broken, but ideally BuildJobsForAction >> would just do the tree traversal, and the details about how to do that >> are abstracted elsewhere. > > > Makes sense. I'll move triple calculation to buildCudaActions. > How about this http://reviews.llvm.org/D11310 ? --Artem
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits