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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
