[PATCH] D12414: [NVPTX] add an NVPTX-specific alias analysis

Jingyue Wu via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 6 22:47:12 PDT 2015


Never mind. I found Module has a getTargetTriple method.

On Sun, Sep 6, 2015 at 10:46 PM, Jingyue Wu <jingyue at google.com> wrote:

> jingyue added inline comments.
>
> ================
> Comment at: lib/Target/NVPTX/NVPTXAliasAnalysis.cpp:71
> @@ +70,3 @@
> +      if (auto A = dyn_cast<Argument>(Obj)) {
> +        if (TM && TM->getDrvInterface() == NVPTX::CUDA &&
> +            isKernelFunction(*A->getParent()))
> ----------------
> hfinkel wrote:
> > jingyue wrote:
> > > hfinkel wrote:
> > > > Can you please explain why this DvrInterface == CUDA check is
> necessary? isKernelFunction always checks for NVVM metadata, and lacking
> that, a specific calling convention. Is that not enough?
> > > >
> > > Sure. As mentioned in the comment, if `Obj` is a **CUDA** kernel
> parameter, it must reside in global memory. But if the driver interface is
> NVCL, for example, a kernel parameter is not guaranteed to point to global
> memory.
> > >
> > > This is also why we have a similar check in `NVPTXLowerKernelArgs`:
> https://github.com/llvm-mirror/llvm/blob/master/lib/Target/NVPTX/NVPTXLowerKernelArgs.cpp#L201
> .
> > Okay; I did not realize this might not hold for NVCL.
> >
> > This it the only place you use TM in this pass, and thus, the only check
> that can't be done early in the pipeline. However, the driver interface
> variable is (at least currently) completely determined by the target
> triple. Is it worth checking the triple directly and dropping the direct TM
> dependency?
> >
> I wanted to avoid using `TM` too, but wonder how I can get it without
> passing in `TargetMachine`.
>
>
> http://reviews.llvm.org/D12414
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150906/3520bbc8/attachment.html>


More information about the llvm-commits mailing list