OpenCL address space and mangling

[Tanya Lattner]

Michele,

On Jul 19, 2013, at 12:50 AM, Michele Scandale <michele.scandale at gmail.com> wrote:

> Hi Tanya,
> 
> thanks for the answer.
> 
>> It doesn't make sense to me to not translate the address space to something meaningful (something other than a random number). Targets should define the address space map if they are supported.
>> What problem are you trying to solve?
> 
> The fact is that on targets, like X86, the address space translation produces for opencl (and cuda) address spaces the same number (zero) because as you said the target itself does not have different physical address spaces.
> 
> In the example attached to the previous mail, you can see that if you try to compile it for X86, clang crashes because:
> 
> __attribute__((overloadable)) void foo(__global float *a)
> 
> and
> 
> __attribute__((overloadable)) void foo(__local float *a)
> 
> are mangled in the same way because of address space translation.
> 
> The logical address space information is lost with this mangling scheme.
> 
> My doubt is about the handling of address space information in the mangling:
> - if the information about logical address spaces must be preserved then the usage of target translation map cannot be used
> - otherwise I don't see why I should manage in different way those cases where the private address space is used from those where the mapping is the private address space.
> 
> From a quick discussion on the IRC channel I found that information must be preserved because I cannot assume that if two overloaded functions where the unique difference is an address space qualifier then if the two address spaces are the same the actions in those function are the same.
> 

I understand what you are saying, but I'm arguing that the Target needs to define the address space map in order for this to mean anything at all. If its not defined, then what does global or local mean? What happens when this is lowered to LLVM IR? 

Why not define an address space map for X86?

-Tanya


> I agree with you that the clang internal encoding of opencl/cuda address spaces is not a wonderful solution, but at least it preserves the information correctly. Maybe another solution (it's just a claim, I don't know if it's feasible) can be the mangling specialization for opencl and cuda, adding a prefix that identifies the programming model and using canonical values for the address spaces (1 = opencl/cuda global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant).
> 
> I hope to have been more clear presenting the problem.
> 
> Thanks in advance.
> 
> Best Regards,
> 
> Michele Scandale
>