search for: ptx_

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? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists...

...icah <Micah.Villmow at amd.com<mailto: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_devic...

...t;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 conve...

...ow 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 reas...

...icah <Micah.Villmow at amd.com<mailto: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_devic...

...f also is > different than the default calling convention because it has restrictions > on it(one being it can only be called from a kernel function or another > device function) that the normal calling convention does not. A way to > think about this is that this is more similar to the PTX_[Kernel|Device] > calling conventions than the default, fast or stdcall conventions. I don't > think metadata is the right approach here since we are specifying unique > ways for how these functions can be called. For what it's worth, this issue manifests itself in an unsolved pocl...

...ow 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 reas...

...gular function itself also is different than the default calling convention because it has restrictions on it(one being it can only be called from a kernel function or another device function) that the normal calling convention does not. A way to think about this is that this is more similar to the PTX_[Kernel|Device] calling conventions than the default, fast or stdcall conventions. I don't think metadata is the right approach here since we are specifying unique ways for how these functions can be called. > 2. A way to remove remnants of the platform or C calling convention. > In th...

Hi Boaz, David, Thanks for taking my responses on board. > 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? Hmm, this is the one I was most shaky on. I still don't fully understand

Hi James, This is very good feedback. 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? 2. Restricting the allowable instructions - As Micah mentioned before, the restrictions are there