r242085 - [cuda] Driver changes to compile and stitch together host and device-side CUDA code.

[Artem Belevich]

On Fri, Jul 17, 2015 at 1:01 PM, Artem Belevich <tra at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150717/1abd67b0/attachment.html>