OpenCL address space and mangling

[Michele Scandale]

Up.

On 07/24/2013 04:49 PM, Michele Scandale wrote:
> 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
>