OpenCL address space and mangling

[Michele Scandale]

> This discussion probably should be moved to the cfe-dev mailing list. I think
> that its better for Clang to have one consistent way of mangling address spaces
> regardless of language. I’ve been thinking about this more and another  problem
> I have with not using the Target address space map for mangling is that when you
> have this:
>
> void __attribute__((__overloadable__)) foo(global int *x)
>
> You get this:
> define void @_Z3fooPU10AS16776960b(i8* %x)
>
> The address space on the argument is gone (or zero), but yet you have it in the
> mangled name. So its not consistent.

Why it's not consistent? In the IR at this time, the addrspace modifier 
represent TARGET/physical address spaces, not LANGUAGE/logical address spaces.
In fact as said it would be useful to represent also logical address spaces in 
the IR, but this is another problem not strictly related to the mangler.

> I can agree that its right to mangle the names differently from the language
> perspective, but what you mangle them to is really target specific. If you want

The last patch I proposed allow to have a translation map for opencl/cuda 
address spaces that can be overwritten by targets, so that the mangling can be 
tuned in order to have binary compatibility with other/pre-existing libraries.
A default map is used in order to have that all target have a consistent 
mangling (no name collisions) in order to fix the problem strictly related to 
the mangler.

> I can agree that its right to mangle the names differently from the language
> perspective, but what you mangle them to is really target specific. If you want
> to remove this notion from Clang, then maybe all target specific address space
> maps should go away and a default one for all is used. Then each LLVM backend
> can interpret it as they wish.

As you said mangling is implementation specific, so this allow to have various 
solutions: the fact that the mangling is TARGET+LANGUAGE specific is perfectly 
fine. Because of this I proposed the patch that introduce the map to translate 
address spaces from the internal representation to the logical representation 
(in principle different from the physical representation): with this solution 
the mangling reflect its intrinsic dependency from language concepts, like 
logical address spaces having the target dependency that allow each target to 
change this mapping, e.g. to have binary compatibility.

Again, the fact that logical address spaces are not also inside the IR as 
property of pointer types is missing feature IMO. Fixing the mangler would then 
allow to start the fixing of this other problem.

Thanks.

Best Regards,

-Michele