(C++) mangling vector types

(C++) mangling vector types

[Jason Merrill]

The G++ mangling of SIMD vector types (SSE, Altivec, etc.) is 
fundamentally broken as it doesn't currently encode the size of the 
vector, only the element type.  So overloading of different size vectors 
fails.  It seems when I implemented this I was modeling the Altivec 
__vector qualifier, which doesn't generalize very well at all...

Clearly, we need to fix this, and the ABI committee has been settling on 
a new mangling.

The question is, how should we handle the transition?

Should the default behavior in 4.5 be:

1) Leave the current mangling as is
2) Leave the current mangling as is for the most common vector size on a 
target (SSE, Altivec) and use the new mangling for other vector sizes.
3) Switch to the new mangling

And what flag should we use to control it?  We're currently at 
-fabi-version=2.  -fabi-version=3 currently changes the mangling of the 
address of a variable or function used as a template argument.

a) Add the vector change to the current ABI v3.
b) Take over -fabi-version=3 and bump the template arg change to v4.
c) Use -fabi-version=2.1.
d) Use a separate flag to control vector mangling.

Opinions?

Jason

Re: (C++) mangling vector types

[Richard Henderson]

On 11/12/2009 07:24 AM, Jason Merrill wrote:
> 1) Leave the current mangling as is
> 2) Leave the current mangling as is for the most common vector size on a
> target (SSE, Altivec) and use the new mangling for other vector sizes.
> 3) Switch to the new mangling

I vote for 2.

> a) Add the vector change to the current ABI v3.
> b) Take over -fabi-version=3 and bump the template arg change to v4.
> c) Use -fabi-version=2.1.
> d) Use a separate flag to control vector mangling.

I vote for [^cd].  I have no preference between v3 and v4, but a 
separate flag seems weird, as does injecting a version number in between 
2 and 3.


r~

Re: (C++) mangling vector types

[Ulrich Drepper]

On 11/12/2009 07:24 AM, Jason Merrill wrote:
> c) Use -fabi-version=2.1.

I'd favor this if you can emit aliases with the old names wherever this 
is possible and currently done.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Re: (C++) mangling vector types

[Daniel Jacobowitz]

On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote:
> On 11/12/2009 07:24 AM, Jason Merrill wrote:
> >1) Leave the current mangling as is
> >2) Leave the current mangling as is for the most common vector size on a
> >target (SSE, Altivec) and use the new mangling for other vector sizes.
> >3) Switch to the new mangling
> 
> I vote for 2.

Does anyone know of another relevant compiler?  What does it do?
For instance, if someone can hand me a test case, I could check how
ARM's compilers mangle it (or don't).

-- 
Daniel Jacobowitz
CodeSourcery

Re: (C++) mangling vector types

[Jason Merrill]

On 11/12/2009 11:14 AM, Ulrich Drepper wrote:
> On 11/12/2009 07:24 AM, Jason Merrill wrote:
>> c) Use -fabi-version=2.1.
>
> I'd favor this if you can emit aliases with the old names wherever this
> is possible and currently done.

I suppose if we unconditionally use the new mangling and emit a weak 
alias with the old mangling, old external references will resolve to 
somthing, so code that only uses one vector size will continue to work; 
if newer code uses multiple vector sizes then references in old code may 
resolve to the wrong one, but that seems unavoidable.

I suppose that is the best solution, as a partial rebuild of an old code 
base should continue to work in all cases, and all new code will also 
work fine.

Jason

Re: (C++) mangling vector types

[Ulrich Drepper]

On 11/12/2009 08:35 AM, Jason Merrill wrote:
>> I'd favor this if you can emit aliases with the old names wherever this
>> is possible and currently done.
>
> I suppose if we unconditionally use the new mangling and emit a weak
> alias with the old mangling, old external references will resolve to
> somthing, so code that only uses one vector size will continue to work;

Really?  How'd you create code with the new compiler and older libraries 
which only provide definitions for the old names?

If I'm not missing anything then using a 2.1 ABI version makes sense 
since it is upward compatible, other than other ABI breakages.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Re: (C++) mangling vector types

[Joseph S. Myers]

On Thu, 12 Nov 2009, Daniel Jacobowitz wrote:

> On Thu, Nov 12, 2009 at 08:10:13AM -0800, Richard Henderson wrote:
> > On 11/12/2009 07:24 AM, Jason Merrill wrote:
> > >1) Leave the current mangling as is
> > >2) Leave the current mangling as is for the most common vector size on a
> > >target (SSE, Altivec) and use the new mangling for other vector sizes.
> > >3) Switch to the new mangling
> > 
> > I vote for 2.
> 
> Does anyone know of another relevant compiler?  What does it do?
> For instance, if someone can hand me a test case, I could check how
> ARM's compilers mangle it (or don't).

It seems clear to me that on ARM, generic vectors corresponding to NEON 
vector types should be mangled the same as the corresponding NEON types 
(whose mangling is specified in AAPCS), even when NEON is disabled, just 
as they follow AAPCS for argument passing and return (including when the 
VFP ABI is enabled and VFP but not NEON is supported).  (Since generic 
vectors may have other combinations of element type and size than those 
supported by NEON and listed in AAPCS, the general issue does still apply 
on ARM for such other generic types.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: (C++) mangling vector types

[Jason Merrill]

On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
> On 11/12/2009 08:35 AM, Jason Merrill wrote:
>>> I'd favor this if you can emit aliases with the old names wherever this
>>> is possible and currently done.
>>
>> I suppose if we unconditionally use the new mangling and emit a weak
>> alias with the old mangling, old external references will resolve to
>> somthing, so code that only uses one vector size will continue to work;
>
> Really? How'd you create code with the new compiler and older libraries
> which only provide definitions for the old names?

Ah, good point.  That would require some sort of "really weak definition".

Jason

Re: (C++) mangling vector types

[Mark Mitchell]

Richard Henderson wrote:

> On 11/12/2009 07:24 AM, Jason Merrill wrote:
>> 1) Leave the current mangling as is
>> 2) Leave the current mangling as is for the most common vector size on a
>> target (SSE, Altivec) and use the new mangling for other vector sizes.
>> 3) Switch to the new mangling
> 
> I vote for 2.

Me too.  Never break backwards compatibility unless really necessary.
We might want to note these special cases in the actual ABI document,
since my impression is that most other compilers are trying to follow G++.

>> b) Take over -fabi-version=3 and bump the template arg change to v4.

I'm not sure what "take over" means, but I think this change should be
in v4.  People might be using v3, and we shouldn't break their world.
Introducing 2.1, or a separate flag, seems odd to me; there's nothing
particularly more or less different about this change then other
mangling changes, as far as I can tell.  It's another case where we've
discovered an inability to implement the full language with the current
scheme, and have therefore been forced to make a change.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: (C++) mangling vector types

[Jason Merrill]

On 11/12/2009 01:18 PM, Mark Mitchell wrote:
>>> b) Take over -fabi-version=3 and bump the template arg change to v4.
>
> I'm not sure what "take over" means, but I think this change should be
> in v4.  People might be using v3, and we shouldn't break their world.
> Introducing 2.1, or a separate flag, seems odd to me; there's nothing
> particularly more or less different about this change then other
> mangling changes, as far as I can tell.  It's another case where we've
> discovered an inability to implement the full language with the current
> scheme, and have therefore been forced to make a change.

There is a difference from v3, which is just a correction to match the 
ABI document; it doesn't prevent us from implementing the full language, 
which is why we never bumped the default.  So I would like to be able to 
make the vector change without also making the template arg change.

Jason

Re: (C++) mangling vector types

[Dave Korn]

Jason Merrill wrote:
> On 11/12/2009 11:50 AM, Ulrich Drepper wrote:
>> On 11/12/2009 08:35 AM, Jason Merrill wrote:
>>>> I'd favor this if you can emit aliases with the old names wherever this
>>>> is possible and currently done.
>>>
>>> I suppose if we unconditionally use the new mangling and emit a weak
>>> alias with the old mangling, old external references will resolve to
>>> somthing, so code that only uses one vector size will continue to work;
>>
>> Really? How'd you create code with the new compiler and older libraries
>> which only provide definitions for the old names?
> 
> Ah, good point.  That would require some sort of "really weak definition".
> 
> Jason

  :)  Wow, that'd be probably the first time ever windows platform semantics
would turn out to support C++ better than ELF semantics!  (We have 'really
weak' definitions, in fact it's the only kind we have...)

    cheers,
      DaveK

Re: (C++) mangling vector types

[Mark Mitchell]

Jason Merrill wrote:

> There is a difference from v3, which is just a correction to match the
> ABI document; it doesn't prevent us from implementing the full language,
> which is why we never bumped the default.  So I would like to be able to
> make the vector change without also making the template arg change.

I understand the argument, but it sounds overly complicated.  Or else
not complicated enough.  If we no longer think that a linear progression
of ABI versions is sufficient, then we should have switches for picking
your point in the multi-dimensional space, rather than just a numerical
version.  That sounds theoretically right to me, but awfully complicated
in practice.

Do we have another libstdc++ ABI change coming?  I'd suggest doing this
as -fabi-version=4, and making that the default at that point.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: (C++) mangling vector types

[Jason Merrill]

On 11/12/2009 04:32 PM, Mark Mitchell wrote:
> I understand the argument, but it sounds overly complicated.  Or else
> not complicated enough.  If we no longer think that a linear progression
> of ABI versions is sufficient, then we should have switches for picking
> your point in the multi-dimensional space, rather than just a numerical
> version.

I think that a linear progression is sufficient, but I want an 
additional point between 2 and 3 since 2 is the current default and 3 
already has meaning.  Thus the 2.1 suggestion.

> That sounds theoretically right to me, but awfully complicated
> in practice.
>
> Do we have another libstdc++ ABI change coming?  I'd suggest doing this
> as -fabi-version=4, and making that the default at that point.

We do; once C++0x is finalized we will need to switch to non-refcounted 
strings and support constant time list.size().  But I believe the plan 
is to manage that transition with namespace versioning so that old and 
new code can continue to coexist as long as they aren't actually trying 
to share affected data structures.

Jason

Re: (C++) mangling vector types

[Mark Mitchell]

Jason Merrill wrote:

> I think that a linear progression is sufficient, but I want an
> additional point between 2 and 3 since 2 is the current default and 3
> already has meaning.  Thus the 2.1 suggestion.

But, there's no longer a total ordering on ABIs; 3 isn't "bigger than"
2.1 anymore.  (Presumably 4 would contain both the change in 3 and the
change in 2.1, so the ordering becomes sensible from that point forward
again.)

>> Do we have another libstdc++ ABI change coming?  I'd suggest doing this
>> as -fabi-version=4, and making that the default at that point.
> 
> We do; once C++0x is finalized we will need to switch to non-refcounted
> strings and support constant time list.size().  But I believe the plan
> is to manage that transition with namespace versioning so that old and
> new code can continue to coexist as long as they aren't actually trying
> to share affected data structures.

So, do you consider ABIv3 there only as a theoretical conformance
option?  In other words, not something we're going to make the default
in any forseeable future?  (Those aren't meant to be rhetorical
questions -- I'm just asking.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: (C++) mangling vector types

[Jason Merrill]

On 11/12/2009 04:48 PM, Mark Mitchell wrote:
> So, do you consider ABIv3 there only as a theoretical conformance
> option?  In other words, not something we're going to make the default
> in any forseeable future?  (Those aren't meant to be rhetorical
> questions -- I'm just asking.)

That has been my thinking, but perhaps it does make sense to make that 
change with the C++0x library deployment; the impact should be pretty 
limited.

I'm surprised to see that EDG doesn't mimic this bug in G++ 
compatibility mode; in fact, they get mangle22.C wrong in a different 
way.  The symbol should be

_Z1g2CBIL_Z3foocEE

-fabi-version=2 gives

_Z1g2CBILZ3foocEE

and EDG 4.1 gives

_Z1g2CBIXL_Z3foocEEE

(extra X/E around the name even though it's an expr-primary).

Jason

Re: (C++) mangling vector types

[Mark Mitchell]

Jason Merrill wrote:

>> So, do you consider ABIv3 there only as a theoretical conformance
>> option?  In other words, not something we're going to make the default
>> in any forseeable future?  (Those aren't meant to be rhetorical
>> questions -- I'm just asking.)
> 
> That has been my thinking, but perhaps it does make sense to make that
> change with the C++0x library deployment; the impact should be pretty
> limited.

I'd also expect that on embedded systems (even embedded GNU/Linux
systems) people won't want the compatibility stuff in libstdc++.
There's not much benefit in backwards compatibility if you're building
everything for your new device, and a lot of benefit in making your
binaries smaller.

So, I still tend to think that the best thing is to put the vector stuff
into v4, and switch that on when we update libstdc++.  I think your
suggest is coherent and well-reasoned, but it seems like a lot of
complexity to deal with a template corner case.

I guess another option is -fabi-version=implement-c++-for-petes-sake
which means "use the ABI that implements as much of the language as
possible".  That would be your version 2.1, but arguably more logically
coherent in that it would be expected to move in the future if/when we
find another feature we can't implement due to current mangling issues.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: (C++) mangling vector types

[Jason Merrill]

On 11/12/2009 05:19 PM, Mark Mitchell wrote:
> So, I still tend to think that the best thing is to put the vector stuff
> into v4, and switch that on when we update libstdc++.  I think your
> suggest is coherent and well-reasoned, but it seems like a lot of
> complexity to deal with a template corner case.

It isn't such a corner case, unfortunately; any code that tries to 
overload on multiple vector sizes (i.e. MMX and SSE vectors) will break. 
  See bug 12909 and its duplicates.  This is becoming more of a problem 
with the advent of the Intel AVX extension.

> I guess another option is -fabi-version=implement-c++-for-petes-sake
> which means "use the ABI that implements as much of the language as
> possible".  That would be your version 2.1, but arguably more logically
> coherent in that it would be expected to move in the future if/when we
> find another feature we can't implement due to current mangling issues.

That seems useful, but I would also want a way to specify a particular 
revision.

Jason

Re: (C++) mangling vector types

[Mark Mitchell]

Jason Merrill wrote:

> It isn't such a corner case, unfortunately; any code that tries to
> overload on multiple vector sizes (i.e. MMX and SSE vectors) will break.
>  See bug 12909 and its duplicates.  This is becoming more of a problem
> with the advent of the Intel AVX extension.

This still seems a lot of complexity to me, and I still think inserting
a new version between 2 and 3 is odd.  If we need the complexity, I
think we have to introduce a new orthogonal option for vector mangling,
independent of the ABI version, but implied by ABI version > 4.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: (C++) mangling vector types

[Gabriel Dos Reis]

On Thu, Nov 12, 2009 at 5:57 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Jason Merrill wrote:
>
>> It isn't such a corner case, unfortunately; any code that tries to
>> overload on multiple vector sizes (i.e. MMX and SSE vectors) will break.
>>  See bug 12909 and its duplicates.  This is becoming more of a problem
>> with the advent of the Intel AVX extension.
>
> This still seems a lot of complexity to me, and I still think inserting
> a new version between 2 and 3 is odd.  If we need the complexity, I
> think we have to introduce a new orthogonal option for vector mangling,
> independent of the ABI version, but implied by ABI version > 4.

How is mangling orthogonal to the ABI?

-- Gaby

Re: (C++) mangling vector types

[Mark Mitchell]

Gabriel Dos Reis wrote:

>> This still seems a lot of complexity to me, and I still think inserting
>> a new version between 2 and 3 is odd.  If we need the complexity, I
>> think we have to introduce a new orthogonal option for vector mangling,
>> independent of the ABI version, but implied by ABI version > 4.
> 
> How is mangling orthogonal to the ABI?

It's certainly possible to have ABIv2-with-vector-change and
ABIv2-without.  I never claimed that they were the same ABI.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713