OpenCL address space and mangling
michele.scandale at gmail.com
Wed Jul 24 07:49:45 PDT 2013
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9471 bytes
Desc: not available
More information about the cfe-commits