________________________________________ From: Gao, Yunzhong Sent: Thursday, February 25, 2016 2:45 PM To: [email protected] Cc: Richard Smith; [email protected] Subject: RE: Mangling for OpenCL and GCC vectors
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; [email protected]; [email protected] 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 > <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >> Richard Smith >> Sent: Friday, February 19, 2016 6:21 PM >> To: Gao, Yunzhong >> Cc: [email protected] >> Subject: Re: Mangling for OpenCL and GCC vectors >> >> On Fri, Feb 19, 2016 at 5:48 PM, Gao, Yunzhong >> <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >>>> Richard Smith >>>> Sent: Friday, February 19, 2016 5:29 PM >>>> To: Gao, Yunzhong >>>> Cc: [email protected] >>>> 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 >>>> <[email protected]> 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; [email protected] >>>>> 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" <[email protected]> >>>>> Date: February 3, 2016 at 5:06:15 PM PST >>>>> To: "[email protected]" <cxx-abi- >> [email protected]> >>>>> Cc: "Robinson, Paul" <[email protected]>, "Gao, >>>> Yunzhong" >>>>> <[email protected]> >>>>> 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 _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
