OpenCL address space and mangling

[Michele Scandale]

On 07/23/2013 11:36 PM, Tanya Lattner wrote:
> However, I actually should have looked at this closer as it actually doesn't map
> to what I want it to. I want it to be the following:
>
> 1, // opencl_global
> 3, // opencl_local
> 2, // opencl_constant
>
> and when there is no address space then it maps to nothing.
>
> So, I don't think your patch is going to work unless the order is changed in the
> enum. Because this is not clearly defined in the spec and is implementation
> specific and TARGET specific..  then changing that enum is probably not going to
> be the right approach either.

I see the point but still we need to preserve the source language difference 
with the mangling.

> So, I'm going back to my original statement to keep it to be Target specific.
> For your library, are these functions actually implemented differently? Wouldn't
> they be exactly the same when there is no address space? In our implementation
> we have an address space map defined for X86 and then  the names get mangled
> "correctly" for all targets. But, all the functionality is the same since the
> address spaces don't impact codegen for X86.

I'd argue that the fact that address spaces do not impact codegen for X86 is 
merely incidental: the issue goes beyond X86 and impacts all targets -- 
including future ones.
By choosing to use a fake address space map (instead of the one fitting the 
target description), we introduce in the IR a potential for breaking future 
implementations, even though the current X86 target is not affected. Moreover, 
by introducing the fake address map we would violate the semantics of the LLVM 
IR addrspace modifier.

Even binary compatibility with libraries already distributed can be easily achieved.

This patch (see attachment) aims at preserving the mangling that were generated 
by using the target address space map for those targets that override it, while 
introducing in the mangling the distinction of opencl/cuda address spaces for 
those targets that do not have a non trivial target address space map.

By the way, looking beyond the scope of the current issue of mangling, it would 
be IMO interesting to start a public discussion on the mailing list about a way 
to represent logical address space information different from target-specific 
address space (the case for OpenCL and CUDA) in order to allow the 
implementation of custom language specific analysis and/or optimization.
As a temporary solution, if one needed the logical address space information in 
the IR too for specific purpose (like OpenCL specific optimization), can still 
override the address space map of the target.

Thanks again.

Regards,

-Michele

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mangling-rev4.patch
Type: text/x-patch
Size: 9471 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130724/9678d9c6/attachment.bin>