OpenCL address space and mangling

Michele Scandale michele.scandale at gmail.com
Fri Jul 19 00:50:03 PDT 2013


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 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




More information about the cfe-commits mailing list