OpenCL C "long" should always have 64 bits

Tom Stellard tom at stellard.net
Tue Sep 3 10:53:31 PDT 2013


On Tue, Sep 03, 2013 at 01:34:50PM -0400, Erik Schnetter wrote:
> Yes, R600 defines a "good" address space map.
> 
> My patch currently overrides the target-specific address space maps...
> 
> Instead of doing so, I think the right approach is to define a default address space map that already does the right thing for OpenCL and CUDA. This makes sense since address spaces seem currently defined for OpenCL and CUDA only, i.e. they won't be used by standard C/C++. The targets can then override the default (which they already do).
> 

Does the rest of this patch depend on resolving the mangling issues with
address spaces?  If not, can we split the address space map out into a
separate patch and commit the rest of the changes?  The OpenCL type
changes are very useful, and I wouldn't want the address space mapping
discussions to prevent them from being committed.

-Tom

> -erik
> 
> On 2013-09-03, at 13:08 , Tom Stellard <tom at stellard.net> wrote:
> 
> > On Tue, Sep 03, 2013 at 12:45:21PM -0400, Erik Schnetter wrote:
> >> Unfortunately, removing the address space definitions means that overloaded functions do not use address spaces for name mangling. This is bad, because OpenCL C's run-time library defines many functions with signatures that differ only in their address spaces. Clang also contains test cases that explicitly assume that e.g. the "global" address space is number 1, and the "constant" address space is number 2.
> >> 
> > 
> > The name mangling works fine when compiling libclc
> > (http://libclc.llvm.org/) for the R600 target.  I'm guessing that this
> > is because R600 defines its own address space map.  Would it work to add
> > an address space map to whatever target you are using?  Or maybe a
> > default address space map that targets like R600 can override.
> > 
> > -Tom
> > 
> >> Given that name mangling is important, I want to re-introduce it, probably as:
> >> 
> >>    static const LangAS::Map OpenCLAddrSpaceMap = {
> >>      /* opencl_global   */ 1,
> >>      /* opencl_local    */ 3,
> >>      /* opencl_constant */ 2,
> >>    };
> >>    AddrSpaceMap = &OpenCLAddrSpaceMap;
> >> 
> >> This order for these magic numbers make Clang's OpenCL test cases pass... not happy about this magic.
> >> 
> >> Is there a different way to ensure that address spaces are used for name mangling? In particular, using address space 0 for several of these does not work in mangled names.
> >> 
> >> -erik
> >> 
> >> On 2013-09-02, at 13:08 , Erik Schnetter <schnetter at gmail.com> wrote:
> >> 
> >>> I attach an updated patch that
> >>> 
> >>> (1) also sets sizeof(int) to 32 bits; short and char are hardwired in Clang;
> >>> (2) does not introduce address spaces any more.
> >>> 
> >>> -erik
> >>> 
> >>> On 2013-09-02, at 9:04 , David Tweed <david.tweed at arm.com> wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> | The address space map IMO should not be imposed, because it represents how a
> >>>> | given OpenCL address space should be mapped to target address space that the
> >>>> | target backend is able to handle.
> >>>> 
> >>>> I think that the view on how to represent OpenCL address spaces (front-end vs back-end) has changed since I first posted my patch, and I agree this is now inappropriate to hardwire what's now a backend value for all targets.
> >>> 
> >>> -- 
> >>> Erik Schnetter <schnetter at gmail.com>
> >>> http://www.perimeterinstitute.ca/personal/eschnetter/
> >>> 
> >>> My email is as private as my paper mail. I therefore support encrypting
> >>> and signing email messages. Get my PGP key from http://pgp.mit.edu/.
> >>> <OpenCL-long.diff>
> >> 
> >> -- 
> >> Erik Schnetter <schnetter at gmail.com>
> >> http://www.perimeterinstitute.ca/personal/eschnetter/
> >> 
> >> My email is as private as my paper mail. I therefore support encrypting
> >> and signing email messages. Get my PGP key from http://pgp.mit.edu/.
> >> 
> > 
> > 
> > 
> >> _______________________________________________
> >> cfe-commits mailing list
> >> cfe-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> > 
> 
> -- 
> Erik Schnetter <schnetter at gmail.com>
> http://www.perimeterinstitute.ca/personal/eschnetter/
> 
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from http://pgp.mit.edu/.
> 





More information about the cfe-commits mailing list