similar to: [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?**** >

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<mailto:Micah.Villmow at amd.com>> wrote: Currently, PTX has its own calling conventions where

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**** > > ** ** >

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<mailto:Micah.Villmow at amd.com>> wrote: From: Justin Holewinski [mailto: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

2011/12/14 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> > Hi all, > > On 12/13/2011 10:50 PM, Justin Holewinski wrote: > > You mean having no calling convention for device functions, and a new, > common > > calling convention for kernels? > > I think this might make sense. > To be clear, I do like the idea of using the default calling convention for

2011/12/14 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> > On 12/14/2011 02:41 PM, Justin Holewinski wrote: > >> I would favor calling conventions over metadata for the simple reason >> that this maps more cleanly to the device model. Device and kernel >> functions are represented differently in PTX, including (sometimes) the >> way parameters are passed.

On 12/14/2011 02:41 PM, Justin Holewinski wrote: > I would favor calling conventions over metadata for the simple reason > that this maps more cleanly to the device model. Device and kernel > functions are represented differently in PTX, including (sometimes) the > way parameters are passed. For the record, marking the kernels with "calling conventions" instead of metadata

Hi all, On 12/13/2011 10:50 PM, Justin Holewinski wrote: > You mean having no calling convention for device functions, and a new, common > calling convention for kernels? I think this might make sense. One major issue with OpenCL C (and I suppose CUDA) kernels some fail to see is that the functions are "directly callable" (just by choosing a correct the calling convention) in

Hi all, >>> I would favor calling conventions over metadata for the simple >>> reason that this maps more cleanly to the device model. Device and >>> kernel functions are represented differently in PTX, including >>> (sometimes) the way parameters are passed. >> For the record, marking the kernels with "calling conventions" >> instead

On Tue, 10 Aug 2010 14:21:43 -0500 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu > > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David A. Greene > > Sent: Tuesday, August 10, 2010 12:05 PM > > To: Helge Rhodin > > Cc: llvmdev at cs.uiuc.edu > >

On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Alberto, >  The AMDIL backend solves your problem with intrinsic overloading this way: > def int_AMDIL_mad     : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; > > Where TernaryIntFloat is defined as: > class TernaryIntFloat : >          Intrinsic<[llvm_anyfloat_ty],

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of David A. Greene > Sent: Tuesday, August 10, 2010 12:05 PM > To: Helge Rhodin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] PTX backend, BSD license > > Helge Rhodin <helge.rhodin at alice-dsl.net> writes: > > >> But I

I am proud to announce that AMD is Open Sourcing AMDIL Code Generator for LLVM 2.9. While this version is not for uptake into LLVM mainline, it does build and is compatible with LLVM 2.9. This is the first step of the process, so I know there will be issues that show up. In the next few months, we will be providing more unit tests and an LLVM 3.0 compatible version, and finally a TOT version for

On Nov 23, 2011 8:33 AM, "Justin Holewinski" <justin.holewinski at gmail.com> wrote: > > > On Nov 23, 2011 6:57 AM, "Alberto Magni" <alberto.magni86 at gmail.com> wrote: > > > > On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > > Alberto, > > > The AMDIL backend solves your problem

Alberto, The AMDIL backend solves your problem with intrinsic overloading this way: def int_AMDIL_mad : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; Where TernaryIntFloat is defined as: class TernaryIntFloat : Intrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>], []>; This allows us to write a

On Nov 23, 2011 6:57 AM, "Alberto Magni" <alberto.magni86 at gmail.com> wrote: > > On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > Alberto, > > The AMDIL backend solves your problem with intrinsic overloading this way: > > def int_AMDIL_mad : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; >

On Mon, Nov 21, 2011 at 5:31 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <alberto.magni86 at gmail.com> > wrote: >> >> On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski >> <justin.holewinski at gmail.com> wrote: >> > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni >> >

On Sun, Dec 4, 2011 at 1:10 PM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Hi Justin, > > sorry for the delay, I have been busy. > > Micah's proposal requires to move the definitions of the intrinsics > from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td > thus allowing the generation of the file PTXGenIntrinsics.inc which > will be

On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?