similar to: [LLVMdev] [RFC] Proposal to make LLVM-IR endian agnostic

On 10/03/2011 09:36 PM, Villmow, Micah wrote: > One of the projects I am working on with others is to make LLVM-IR endian agnostic. > > > > So, I am sending out this proposal for feedback to the LLVM community. I’ve attached > > pretty version of the proposal in PDF format and pasted a 80-column safe text version > > below. > > > > A second smaller

Hi Micah, I'm no core developer, but FWIW here are my thoughts: I'm general I think the patch is too OpenCL oriented, and I have some niggling qualms about other parts. Specifically (comments inline): From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: 03 October 2011 19:37 To: llvmdev at cs.uiuc.edu Subject:

From: James Molloy [mailto:james.molloy at arm.com] Sent: Tuesday, October 04, 2011 12:06 AM To: Villmow, Micah; llvmdev at cs.uiuc.edu Subject: RE: [RFC] Proposal to make LLVM-IR endian agnostic Hi Micah, I'm no core developer, but FWIW here are my thoughts: I'm general I think the patch is too OpenCL oriented [Villmow, Micah] I agree, but this is mainly to solve a problem that is

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

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, September 12, 2012 3:50 PM > To: Villmow, Micah > Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion > > On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com> >

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

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

I wonder if this could be handle specifying that certain address spaces have one or another endianness, which is not necessarily the same as the processor endianness. Your main requirement seems to be that you need to access to banks of memory, with different endianess, and that you the first stage IR to be able to be run on either endianness processor, without change. I would assume that any

On Wed, Sep 12, 2012 at 3:40 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > > > > From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard > Smith > Sent: Wednesday, September 12, 2012 3:30 PM > To: Villmow, Micah > Cc: Eli Friedman; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > > Subject: Re: [cfe-dev] [LLVMdev] SPIR

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

On Wed, Sep 12, 2012 at 4:02 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Eli Friedman [mailto:eli.friedman at gmail.com] >> Sent: Wednesday, September 12, 2012 3:50 PM >> To: Villmow, Micah >> Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu >> Subject: Re: [cfe-dev] [LLVMdev] SPIR

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, September 12, 2012 3:22 PM > To: Villmow, Micah > Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] SPIR Portability Discussion > > On Wed, Sep 12, 2012 at 2:58 PM, Villmow, Micah <Micah.Villmow at amd.com> >

> > > > +enum OpenCLAddressSpace { > > > > + OPENCL_PRIVATE = 0, > > > > + OPENCL_GLOBAL = 1, > > > > + OPENCL_LOCAL = 2, > > > > + OPENCL_CONSTANT = 3 > > > > +}; > -----Original Message----- > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > Anton, > Would there be any issue with switching

On Wed, Sep 12, 2012 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > > > > -----Original Message----- > > From: Eli Friedman [mailto:eli.friedman at gmail.com] > > Sent: Wednesday, September 12, 2012 3:22 PM > > To: Villmow, Micah > > Cc: Richard Smith; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > Subject: Re: [cfe-dev] [LLVMdev]

The problem is that we use the ordering private, global, constant and local, and this is the same ordering that is used on Apple as well. As we already have OpenCL binaries out in public, making the change is problematic as we want to keep backward compatibility at all costs. Thanks, Micah > -----Original Message----- > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > Sent:

On Mon, Dec 6, 2010 at 6:16 PM, 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 Peter Collingbourne >> Sent: Monday, December 06, 2010 2:56 PM >> To: David Neto >> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu >>

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:

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

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