OpenCL address space and mangling

[Mon Ping Wang]

On Aug 1, 2013, at 11:12 AM, Michele Scandale <michele.scandale at gmail.com> wrote:

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

Sorry of being late to this conversation. It doesn’t look consistent me. Address space numbers are not language constructs.   The language constructs are global and local.  Coming out of clang, I think it is more natural for the AS mangling and the type to match.  
In C++, clang will generate different names for structures which can be identical and uses those names consistently to mangle the function, e.g.,
  %struct.foo = type { i32, i32 }
  define void @_Z4testR3foo(%struct.foo* %foo) 

I view the address spaces coming out of clang represent how the target represent memory is a logical.  How a particular llvm maps them to physical memory is target dependent.  A backend may map them all the address spaces to the same physical memory or to different ones.  Due to this, I don’t think it make sense to distinguish between the two in clang for a particular target.

Best regards,
  — Mon Ping



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130801/4b3dc7f8/attachment.html>