[LLVMdev] Changes to the PTX calling conventions

[Justin Holewinski]

On Tue, Dec 13, 2011 at 3:37 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote:

>  ** **
>
> *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com]
> *Sent:* Tuesday, December 13, 2011 10:50 AM
>
> *To:* Villmow, Micah
> *Cc:* LLVM Developers Mailing List
> *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions****
>
>  ** **
>
> On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:****
>
>  ****
>
>  ****
>
> *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com]
> *Sent:* Tuesday, December 13, 2011 9:48 AM
> *To:* Villmow, Micah
> *Cc:* LLVM Developers Mailing List
> *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions****
>
>  ****
>
> On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:****
>
> Currently, PTX has its own calling conventions where they are split into
> kernel/device. ****
>
> The AMDIL backend requires very similar calling conventions and I was
> wondering if ****
>
> we could change the calling conventions from PTX_* to something more
> generic?****
>
>  ****
>
> Maybe just Kernel/Device? Or would it be preferable to add a new calling
> convention****
>
> that is unique for each target, even though it duplicates functionality?**
> **
>
>  ****
>
> I don't see any reason why a generic calling convention would not work.
>  We could do something like cl_device/cl_kernel.  I hate to introduce
> OpenCL terms into a back-end where OpenCL is just one consumer, but it does
> map cleanly to the architecture model.  Or perhaps something more generic
> like gpu_device/gpu_global.****
>
> *[Villmow, Micah] Yeah, but this should apply to more than just gpu's.
> For example, AMD's OpenCL CPU implementation could utilize the calling
> conventions, along with projects like ocelot that have the device-only vs
> host/device differentiation. Maybe just device/host is good enough?*****
>
> ** **
>
> Device/host just seems vague.  Maybe we could create a set of specific
> conventions, one set for OpenCL: cl_device/cl_kernel, and another set for
> general accelerators, e.g. accel_device/accel_global.****
>
> *[Villmow, Micah] Yeah, that is true. What about leaving the calling
> convention alone for 'device' and just having a calling convention for
> 'kernel'(i.e. functions callable from another device). The normal calling
> conventions handle calls from the same device, but there is no calling
> convention that handles functions that are callable from a seperate device.
> This would handle the CPU/GPU and accelerator cases. That I believe is the
> fundamental difference between the two calling conventions that OpenCL uses.
> *
>

You mean having no calling convention for device functions, and a new,
common calling convention for kernels?

While this would work in practice, my issue with this approach is that it
goes against the LLVM reference:

*"ccc" - The C calling convention*:This calling convention (the default if
no other calling convention is specified) matches the target C calling
conventions. This calling convention supports varargs function calls and
tolerates some mismatch in the declared prototype and implemented
declaration of the function (as does normal C).

Our devices do not really have a "C calling convention," so the default
does not make much sense.  However, I have no objection to modifying the
documentation to state that the C calling convention is the default for
targets that support that convention.

* *****
>
>  ****
>
>     ****
>
>   ****
>
> Thanks,****
>
> Micah****
>
>  ****
>
>  ****
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev****
>
>
>
> ****
>
>  ****
>
> -- ****
>
> Thanks,****
>
>  ****
>
> Justin Holewinski****
>
>  ****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> Thanks,****
>
> ** **
>
> Justin Holewinski****
>
> ** **
>



-- 

Thanks,

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