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

Richard Smith richardsmith at google.com
Wed May 13 00:29:13 UTC 2015


Another item for the Itanium C++ ABI version 2 list:

The ABI currently specifies that the initial guard variable load is an
acquire load (3.3.2, "An implementation supporting thread-safety on
multiprocessor systems must also guarantee that references to the
initialized object do not occur before the load of the initialization flag.
On Itanium, this can be done by using a ld1.acq operation to load the
flag.").

This is inefficient on systems where an acquire load requires a fence.
Using an algorithm due to Mike Burrows (described in the appendix of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm) the same
interface can be implemented starting with a relaxed load, where the
acquire operation is performed only the first time each thread hits the
initialization.

On 19 November 2013 at 17:57, Richard Smith <richardsmith at google.com> wrote:

> 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.
>  * Simplify case 2b in non-POD class layout.
>  * Make virtual functions that are defined as 'inline' not be key functions
>  * 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)
>  * 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?
>
>
> 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20150512/9bf70887/attachment.html>


More information about the cxx-abi-dev mailing list