[cfe-dev] OpenCL/CUDA Interop with PTX Back-End

[Justin Holewinski]

On Wed, Oct 5, 2011 at 12:38 PM, Peter Collingbourne <peter at pcc.me.uk>wrote:

> On Wed, Oct 05, 2011 at 12:18:39PM -0400, Justin Holewinski wrote:
> > Peter, one more question.  Is the "opencl.kernels" metadata a permanent
> > thing, or is it a short-term hack?  I ask because I'm working on how to
> > identify kernel vs. device functions in the PTX back-end.  The way I see
> it,
> > I have two options:
> >
> >    1. Use a pass in the back-end to assign the proper calling convention
> to
> >    each function, if the metadata is present.
> >    2. Modify Clang (maybe through an extension of the CGOpenCLRuntime
> class)
> >    to set the proper PTX calling convention when in OpenCL-mode.
>
> I really don't like this metadata at all, and I'd prefer that we get
> rid of it, but I think that ARM's (non-open-source) GPU backend relies
> on it.
>
> I think that the best approach is to modify Clang to set the
> correct calling convention.  Specifically, we can override the
> SetTargetAttributes function in PTXTargetCodeGenInfo to set the
> calling convention based on the presence of the attribute if we are
> in OpenCL mode.
>

I agree, but I wasn't sure if the "opencl.kernels" metadata was the "proper"
way to do it with Clang.

I just committed a patch for this.  The only variation from what you
suggested is an additional check to force device functions to be the default
in PTXABIInfo.  Otherwise, if kernels functions were the default (as could
be the case, depending on triple), then some of the optimization logic was
getting confused and replacing entire functions with llvm.trap calls due to
calling convention mis-matches.  I think the problem had to do with device
functions being marked as kernel functions initially, then changed to device
functions in SetTargetAttributes.


>
> Thanks,
> --
> Peter
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111005/8fae3289/attachment.html>