On Aug 1, 2013, at 11:12 AM, Michele Scandale <michele.scand...@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
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
