similar to: [LLVMdev] [cfe-dev] SPIR provisional specification is now available in the Khronos website

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

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

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, September 11, 2012 8:49 AM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR provisional specifciation is now available > in the Khronos website > > Hi Boaz, >

Hi Boaz, Micah, Thanks for the followup. > I agree with Micah that optimizing a SPIR module might make it less portable. > However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even convert it to another IR. > It would be useful if we could identify areas in the specification

Hi Micah, >> (a) You mention special calling conventions and adding them to LLVM. >> What are their semantics? And what is their purpose? > [Villmow, Micah] One purpose is to differentiate between kernel and device functions. > Another is to differentiate between the standard calling conventions that have > device specific assumptions built into them. Do you have an example

James, here are our updated answers after discussing this. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, September 11, 2012 8:49 AM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR provisional specifciation is now

Hi Boaz, I have a couple of specific questions: (a) You mention special calling conventions and adding them to LLVM. What are their semantics? And what is their purpose? (b) Why disallow type conversion for vector types? (ss. 3.3) Cheers, James On Tue, 2012-09-11 at 12:56 +0100, Ouriel, Boaz wrote: > Hi All, > > In continuation of the previous SPIR introduction email here is a link

On Sep 6, 2012, at 4:33 PM, "Ouriel, Boaz" <boaz.ouriel at intel.com> wrote: > **** Introduction **** > Lately, Khronos has ratified a new provisional specification which is called SPIR. > This specification standardizes an intermediate representation for the OpenCL kernel language. > It is based on LLVM infrastructure and this is why I am sending this mail to the

Hi All, In continuation of the previous SPIR introduction email here is a link to the specification: http://www.khronos.org/registry/cl/specs/spir_spec-1.0-provisional.pdf The first topic which we would like to discuss is "SPIR portability". I will send soon an additional mail which will help in leading the discussion on this topic. Thanks and happy reading, Boaz -----Original

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Vikram Adve > Sent: Thursday, September 06, 2012 3:52 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] "SPIR" ? A Standard Portable IR for OpenCL > Kernel Language > > On Sep 6, 2012, at 4:33 PM, "Ouriel, Boaz"

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 1:55 PM To: Ouriel, Boaz Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at intel.com<mailto:boaz.ouriel at intel.com>> wrote: Hey

On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Richard Smith > *Sent:* Wednesday, September 12, 2012 1:55 PM > *To:* Ouriel, Boaz > *Cc:* cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > *Subject:* Re:

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 2:51 PM To: Villmow, Micah Cc: Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From:

On Wed, Sep 12, 2012 at 12:27 PM, Ouriel, Boaz <boaz.ouriel at intel.com>wrote: > Hey All, > > This is a very big topic in SPIR and probably a very controversial one as > well. It includes dealing with 32 vs. 64 bit architectures and OpenCL "C" > endianness. > We have written down some of the aspects, but of course did not cover > everything - let's start

Hey All, This is a very big topic in SPIR and probably a very controversial one as well. It includes dealing with 32 vs. 64 bit architectures and OpenCL "C" endianness. We have written down some of the aspects, but of course did not cover everything - let's start a discussion on the portability and see where it takes us. I suggest we start with the 32 vs. 64 bits discussion and then

Carlos, AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being

Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is

Greetings All, I am sending this mail on behalf of the OpenCL Khronos members. **** Introduction **** Lately, Khronos has ratified a new provisional specification which is called SPIR. This specification standardizes an intermediate representation for the OpenCL kernel language. It is based on LLVM infrastructure and this is why I am sending this mail to the LLVM mailing list. Khronos members

> -----Original Message----- > From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On Behalf > Of James Molloy > Sent: Wednesday, September 12, 2012 12:18 PM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu; Villmow, Micah > Subject: Re: [cfe-dev] [LLVMdev] SPIR provisional specification is now > available in the Khronos website >

> > ****Pointers**** > During SPIR generation, the size, and the alignment of pointers is unknown (32 vs. 64 bits). > The SPIR representation shouldn't assume anything about the size and the alignment of pointers, > but it might use pointers in the usual way (except from using GEP when the pointed type has unknown size - this one is illegal in SPIR and will fail the