[cxx-abi-dev] Mangling for OpenCL and GCC vectors

Gao, Yunzhong yunzhong_gao at playstation.sony.com
Thu Feb 25 22:45:03 UTC 2016 

To recap, the suggestion was:
  When targeting SPIR, we mangle ext_vector_type as Dv<N>_<T>, where N is
  the number of elements in the vector, and T is the mangled element type;
  and we mangle vector_size as something else. This is consistent with
  SPIR 1.2 and SPIR 2.0 specs.

  When targeting other-than-SPIR, we mangle vector_size as Dv<N>_<T>;
  and we mangle ext_vector_type as something else. This is consistent with
  GCC 5.x.

For this something else, I originally thought we could use the GCC 4.x
mangling, which is U8__vector<T>, where T is the mangled element type, but
this mangling does not describe the number of elements, and therefore
creates a problem where a <8 x float> and a <4 x float> would have the
identical mangling.

Maybe we could use the SPIR 1.0 mangling as described in
www.khronos.org/registry/cl/specs/spir_spec-1.0-provisional.pdf
That is,
  For element size <= 8: use u2v<N><T>
  For element size > 8: use u3v<N><T>
Do you think this might be acceptable?

I notice that clang has a notion of DependentSizedExtVectorType. I am not
sure whether u2v<N><T> or u3v<N><T> would be more appropriate if the number
of elements is unknown at the time of mangling. On the other hand, I
thought the number of elements is always known when a template is
instantiated... is there a use case where a size expression instead of an
actual size survives into the final assembly?

It feels somewhat awkward that we appear to be inventing a mangling scheme
in clang. Do you expect other compilers to eventually do the same trick?
Where should this new mangling scheme be documented?

- Gao

________________________________________
From: Gao, Yunzhong
Sent: Tuesday, February 23, 2016 8:39 PM
To: Gao, Yunzhong
Cc: Richard Smith; rjmccall at apple.com; cxx-abi-dev at codesourcery.com
Subject: Re: Mangling for OpenCL and GCC vectors

Actually, I might have been confused with how SPIR works. I thought OpenCL can target CPU codes, so when compiling an OpenCL program and when compiling a C++ program, they could be targeting the same CPU architecture, so linking is possible. But looking at github.com/KhronosGroup/SPIR, they talk about the SPIR triples as spir-unknown-unknown or spir64-unknown-unknown. So SPIR is being treated as a virtual backend architecture.

Sent from my iPhone

> On Feb 23, 2016, at 7:48 PM, Gao, Yunzhong <yunzhong_gao at playstation.sony.com> wrote:
>
> GCC 4.8.2 follows an older version of GNU ABI, so given,
>  typedef float float4 __attribute__((__vector_size__(16)));
>  void foo(float4 f) { }
> G++ mangles a <4 x float> vector into U8_floatf. And a <2 x double> vector is mangled into U8_floatd.
> I do not have GCC 5.2 or 5.3 but presumably they changed their mangling scheme there.
>
> Clang has always mangled these types into Dv4_f and Dv2_d respectively.
>
> If I use the ext_vector_size attribute instead, which is for OpenCL compatibility,
>  typedef float float4 __attribute__((__ext_vector_size__(4)));
>  void foo(float4 f) { }
> GCC 4.8.2 does not support this attribute.
> Clang always mangles this type into Dv4_f.
>
> I thought about whether the delicate mechanism of swapping mangling would work as you
> described, and I think it depends on whether anyone would want to link OpenCL program
> and C++ programs together, and if so, you may want the OpenCL vector types to have
> matching mangled names. Maybe.
>
> - Gao
>
>
>> -----Original Message-----
>> From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of
>> Richard Smith
>> Sent: Friday, February 19, 2016 6:21 PM
>> To: Gao, Yunzhong
>> Cc: rjmccall at apple.com
>> Subject: Re: Mangling for OpenCL and GCC vectors
>>
>> On Fri, Feb 19, 2016 at 5:48 PM, Gao, Yunzhong
>> <yunzhong_gao at playstation.sony.com> wrote:
>>> Hey Richard,
>>> Thanks! My understanding is that the GCC vector type is being mangled
>>> according to the Itanium ABI
>>
>> The Itanium C++ ABI does not appear to specify any mangling for vector
>> types. This Dv <number> _ <type> mangling is a GNU extension.
>>
>>> and the OpenCL vector type is being mangled according to the SPIR 1.2
>>> spec.
>>
>> SPIR presumably inherited their mangling from whatever Clang did at the
>> time. :-(
>>
>>> So does your answer imply that one of the ABIs need be modified to
>>> reflect a different mangling?
>>
>> There's an alternative: we can do the same dance we do for similar messes,
>> like long double vs __float128 on PPC (the Itanium ABI has both a long double
>> mangling, e, and a __float128 mangling, g, but because of Reasons, the
>> mangling 'g' is used for long double and the mangling u10__float128 is used
>> for __float128, sometimes).
>>
>> So, when targeting SPIR, we'd mangle ext_vector_type as Dv... and mangle
>> vector_size as something else.
>> When targeting anything else, we'd mangle vector_size as Dv... and mangle
>> ext_vector_type as something else.
>>
>>> Any advice on how
>>> to initiate a discussion to change either of the ABIs?
>>> - Gao
>>>
>>>
>>>> -----Original Message-----
>>>> From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of
>>>> Richard Smith
>>>> Sent: Friday, February 19, 2016 5:29 PM
>>>> To: Gao, Yunzhong
>>>> Cc: rjmccall at apple.com
>>>> Subject: Re: Mangling for OpenCL and GCC vectors
>>>>
>>>> I'm not seeing it show up on the list either. FWIW, I think these
>>>> types should have different manglings.
>>>>
>>>> On Fri, Feb 19, 2016 at 4:47 PM, Gao, Yunzhong
>>>> <yunzhong_gao at playstation.sony.com> wrote:
>>>>> Ping?
>>>>>
>>>>> Hmm, still not seeing the mail on the mailing list after two weeks.
>>>>> It’s strange.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: Gao, Yunzhong
>>>>> Sent: Monday, February 08, 2016 9:55 PM
>>>>> To: Richard Smith; rjmccall at apple.com
>>>>> Subject: Fwd: Mangling for OpenCL and GCC vectors
>>>>>
>>>>>
>>>>>
>>>>> Hi John, Richard,
>>>>>
>>>>> I did not see the following email appear on the online cxx-abi-dev
>>>>> archive after the weekend, so I thought to just forward it to you
>>>>> directly. Sorry for the spam.
>>>>>
>>>>>
>>>>>
>>>>> The core issue is that we have two types which clang would consider
>>>>> distinct but which are mangled the same. In this case one could
>>>>> argue that since the linker cannot tell the two types apart (if
>>>>> they came from different translation units) based on their
>>>>> mangling, then the compiler should also treat them the same coming
>>>>> from the same translation unit. But one could also argue that if
>>>>> they are meant to be distinct types, they should have different
>>>>> mangling, and the ABIs need be changed. We cannot decide which is
>>>>> the intention in giving them the same mangling in the first place.
>>>>> Are there any precedent cases with conflicting symbol mangling? How
>> were they resolved?
>>>>>
>>>>> - Gao
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> From: "Yung, Douglas" <douglas_yung at playstation.sony.com>
>>>>> Date: February 3, 2016 at 5:06:15 PM PST
>>>>> To: "cxx-abi-dev at codesourcery.com" <cxx-abi-
>> dev at codesourcery.com>
>>>>> Cc: "Robinson, Paul" <Paul_Robinson at playstation.sony.com>, "Gao,
>>>> Yunzhong"
>>>>> <yunzhong_gao at playstation.sony.com>
>>>>> Subject: Mangling for OpenCL and GCC vectors
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> Recently in our testing we encountered an abi issue that we were
>>>>> hoping to get clarified. Specifically, this concerns the mangling
>>>>> of OpenCL and GCC vectors which seems to be identical when
>>>>> comparing the results of GCC vectors compiled by GCC5 and OpenCL
>>>>> vectors when mangled according to the SPIR 1.2 spec.
>>>>>
>>>>>
>>>>>
>>>>> First a little background. Clang supports using both OpenCL and GCC
>>>>> vectors in a program. When used, clang permits certain operations
>>>>> to be performed on each as detailed in the table found at
>>>>> http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-
>>>> extended-vectors.
>>>>> From the differences there, it seems the compiler treats the types
>>>>> as unique which makes sense as they support different operations.
>>>>>
>>>>>
>>>>>
>>>>> The problem we found arises when you try to use both in the same
>>>> program.
>>>>> Consider the following example:
>>>>>
>>>>>
>>>>>
>>>>> template <typename alpha>
>>>>>
>>>>> static void foo() {}
>>>>>
>>>>>
>>>>>
>>>>> void bar() {
>>>>>
>>>>>  foo<float __attribute__((__vector_size__(16)))>();
>>>>>
>>>>>  foo<float __attribute__((ext_vector_type(4)))>();
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> In this example, the compiler creates two copies of the function
>>>>> foo, once using a GCC vector, and once using an OpenCL vector.
>>>>> These functions mangle to the same string ” _ZL3fooIDv4_fEvv” which
>>>>> the compiler detects and issues an error. Is the fact that the two
>>>>> vectors mangle identically by design or just a coincidence? If it
>>>>> is by coincidence, should the compiler merge the two type
>>>>> definitions when it encounters them, or was there some other
>>>>> intention here that we are
>>>> unaware of?
>>>>>
>>>>>
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>>
>>>>> Douglas Yung

More information about the cxx-abi-dev mailing list