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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >>> 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 <[email protected]> > >> 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 > >> [email protected] > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > > -- > Erik Schnetter <[email protected]> > 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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
