[LLVMdev] [PATCH] OpenCL support - update on keywords

[Villmow, Micah]

Anton,
 We have discussed this internally a little bit. What about encoding the address space definition into the data layout string? That way various vendors can be compatible with each other. For example if the CL was generated by clang, it would have:
target datalayout = "e-p:32:32:32-addr0:private-addr1:global-addr2:local-addr3:constant-i1:8:8-i8:8:8-i16:16:16"
but our frontend would generate: 
target datalayout = "e-p:32:32:32-addr0:private-addr1:global-addr2:constant-addr3:local-i1:8:8-i8:8:8-i16:16:16"
This information can be ignored on platforms that don't support multiple address spaces and would allow dynamic mapping so that the back end's do not need to have different modes for each different frontend.

Micah



> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Villmow, Micah
> Sent: Monday, February 21, 2011 10:27 AM
> To: Anton.Lokhmotov at arm.com; 'Peter Collingbourne'
> Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [PATCH] OpenCL support - update on keywords
> 
> 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: Monday, February 21, 2011 1:45 AM
> > To: Villmow, Micah; 'Peter Collingbourne'
> > Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
> > Subject: RE: [PATCH] OpenCL support - update on keywords
> >
> > > > > > +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 the ordering of constant
> > and
> > > local?
> >
> > Hi Micah,
> >
> > We'd rather not do that.  First, this order follows the order of
> > subsections
> > in 6.5 of the OpenCL specification, with global described in 6.5.1,
> > local in
> > 6.5.2, constant in 6.5.3; private is described in 6.5.4 but it's also
> > the
> > default function-scope space which is 0.  Second, we use the same
> order
> > in
> > our (non-LLVM) GPU backend.
> >
> > Best regards,
> > Anton.
> >
> >
> >
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev