[cxx-abi-dev] C++ ABI version 2

[Michael Wong]

I understand many of these are picked from the ARM C++ ABI suggestions and
as Michael Gschwinn commented ARM have also pulled back which make me
suspicious as to whether there are data to show these ideas are
consistently good performance wins, or just sometimes wins. And if its an
always win, then it might be worth the ABI breakage.  In this note, I am
hoping to get a clearer idea of what they are and some feedback on whether
they are always a win. But thanks Richard for suggestion some of these as
we have been looking at some of these as well. More questions embedded
below.


cxx-abi-dev-bounces at codesourcery.com wrote on 11/19/2013 08:57:50 PM:

> From:
>
> Richard Smith <richardsmith at google.com>
>
> To:
>
> "cxx-abi-dev at codesourcery.com" <cxx-abi-dev at codesourcery.com>,
>
> Date:
>
> 11/19/2013 08:58 PM
>
> Subject:
>
> [cxx-abi-dev] C++ ABI version 2
>
> Sent by:
>
> cxx-abi-dev-bounces at codesourcery.com
>
> Hi,
>
> There are a few things in the current ABI which are known to be
> suboptimal, but we cannot change because doing so would introduce an
> ABI break. However, vendors sometimes get an opportunity to break
> their ABI (or are defining a new ABI), and for some vendors, this is
> a very common occurrence. To this end, I think it would be valuable
> for the ABI document to describe what we might want to put in a
> 'Version 2' of the ABI; that is, a set of changes that we recommend
> be made whenever a vendor has a chance to introduce an ABI break.
>
> (Or perhaps this should be viewed from the opposite perspective: we
> could make improvements to the ABI, with an annex listing changes
> that old platforms must make for compatibility.)
>
> Would there be support for this idea?
>
> In off-line discussion with John McCall, we came up with the
> following list of potential changes that might be made (sorry if I
> forgot any):
>
>  * Make constructors and destructors return 'this' instead of
> returning 'void', in order to allow callers to avoid a reload in
> common cases and to allow more tail calls.

This seems like a simple idea, but does it save extra calls in every case
for the cost of the ABI breakage? I think I can think of a few cases where
it will save, but can there be cases where it won't save? Do we think we
will implement this using another set of differently named C1,C2, C3,
D1,D2,D3 to make sure that we know which one return this and which one
return void, otherwise how do implementations tell the difference between
the old set and the new set?

>  * Simplify case 2b in non-POD class layout.
I could not track down what the simplify proposal is in the ARM C++ ABI. Is
this saying we will remove the complication of the search for the
Nearly-Empty base which causes such headache for implementers 10 years ago?
But now that we all have it, is it worth the few weeks that it would take
to pull it out. For us, this code is fairly infused into the whole primary
base search mechanism. Is this simplification something else?

>  * Make virtual functions that are defined as 'inline' not be key
functions

While I like this change because it removes a persistent ambiguity, my
question is do the majority of compilers pick the base that does not have
the out-of-class inline keyword (i.e. the first virtual void f()). We still
pick the out-of-class inline one (the virtual void b()) that is not
declared inlined in the class. This is clearly IMHO against the spirit of
the key function, but don't all compilers do the same thing and if so, why
change it? May be it is better to change the definition to define precisely
what everyone already do and just leave it as a wart?

>  * Fix the bug that -1 is both the null pointer-to-data-member value
> and also a valid value of a pointer-to-data-member (could use
> SIZE_MIN instead)

This is the one I would probably pick to like the most if someone can show
me the ambiguous case. I just could not think of it. Aren't all the offset
to base always positive? Since you said it exists, I believe you so I just
want to see what it is and if so I would agree the fix is needed.

>  * Relax the definition of POD used in the ABI, in order to allow
> more class types to be passed in registers
>
> Are there any other things that it would make sense to change in a
> version 2 of the ABI?

Do we want to specify how dynamic Thread local storage is done? As some can
do it using a Compiler guard, while others can do it through a new OS
section making it non-interopearable?

>
> Also, would there be any support for documenting common deviations
> from the ABI that platform vendors might want to consider when
> specifying their own ABIs? In addition to some of the above, this
> would also include:
>
>  * Representation of pointers-to-member-functions (in particular,
> the current representation assumes that the lowest bit of a function
> pointer is unused, which isn't true in general)
>  * Representation of guard variables (some platforms use the native
> word size rather than forcing this to be 64 bits wide)
>
> Are there any others?
>
> Thanks!_______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev


_________________________________________________________
Regards, Michael
http://isocpp.org/wiki/faq/wg21:michael-wong
OpenMP CEO: http://openmp.org/wp/about-openmp/
My Blogs: http://ibm.co/pCvPHR
C++11 status: http://tinyurl.com/43y8xgf
Boost test results
http://www.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&uid=swg27006911

C/C++ Compilers Feature Request Page
http://www.ibm.com/developerworks/rfe/?PROD_ID=700
TM: https://sites.google.com/site/tmforcplusplus/

IBM Corporation
XL C++ Compiler kernel Development
IBM Canada Ltd., C2/KD2/8200/MKM
8200 Warden Avenue
Markham, Ontario L6G 1C7
W:905-413-3283 F:905-413-4839
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20131128/7f627cc3/attachment.html>