similar to: [LLVMdev] SPIR Portability Discussion

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

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:

Hi All, I would like to open up the discussion on the Host and Device Endianness section of the SPIR portability topic. Please read below section number 2 and send your comments. Thanks, Boaz -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ouriel, Boaz Sent: Wednesday, September 12, 2012 22:27 To: llvmdev at cs.uiuc.edu;

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

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

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

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

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

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 James, some additional comments regarding some of your questions: Q: Is SPIR meant to be storage-only, or to allow optimizations to be done? 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

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

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

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

Hi All, I have made an attempt to summarize the different comments that were raised so far. An answer has been provided inside. Please let me know if I missed any comments or got them wrong. *** Hal Finkel: Handling FP_CONTRACT *** *****Comment: The current specification provides a mechanism for handling FP_CONTRACT, but does so only at the module level. After much debate,

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

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Nadav Rotem > Sent: Wednesday, September 12, 2012 2:05 PM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR Portability Discussion > > > > > > ****Pointers**** > > During