<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 17, 2015 at 1:01 PM, Artem Belevich <span dir="ltr"><<a href="mailto:tra@google.com" target="_blank">tra@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>>     > +  if (const CudaDeviceAction *CDA = dyn_cast<CudaDeviceAction>(A)) {<br>
>     > +    // Figure out which NVPTX triple to use for device-side compilation<br>
>     based on<br>
>     > +    // whether host is 64-bit.<br>
>     > +    llvm::Triple DeviceTriple(C.getDefaultToolChain().getTriple<br>
>     ().isArch64Bit()<br>
>     > +                                  ? "nvptx64-nvidia-cuda"<br>
>     > +                                  : "nvptx-nvidia-cuda");<br>
><br>
>     It seems like a pretty bad layering violation to need to know these<br>
>     particular triples right here...<br>
><br>
> Well, it's up to driver to figure out device-side triple. While I agree that<br>
> it's way too much target knowledge for the driver, I'm short on practical<br>
> ideas. Do you have any suggestions?<br>
<br>
</div></div>I guess I might expect this to be figured out in buildCudaActions, near<br>
where we figure out the device architectures. I guess this triple is<br>
more based on the host-side target though?<br></blockquote><div><br></div></div></div><div>Device triple is assumed to be a variant of NVPTX matching 32/64-bitness of the host.</div><div>I guess I can compute the triple and stash it in CudaDeviceAction along with GPU arch.</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
This is already a little bit broken, but ideally BuildJobsForAction<br>
would just do the tree traversal, and the details about how to do that<br>
are abstracted elsewhere. </blockquote><div><br></div></span><div>Makes sense. I'll move triple calculation to buildCudaActions.</div></div></div></div></blockquote><div><br></div><div>How about this <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11310&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=BSqEv9KvKMW_Ob8SyngJ70KdZISM_ASROnREeq0cCxk&m=HA4J-rJ06lCMIYIFWPVSLG3QA4xBa_4dpyq_b_5ZP-U&s=H_JbdSW3XxzCcXwC_Kv4IPJDkYWeIv7JWCoqncF5qmg&e=">http://reviews.llvm.org/D11310</a> ?</div><div><br></div><div>--Artem</div></div>
</div></div>