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.
[email protected] wrote on 11/19/2013 08:57:50 PM: > From: > > Richard Smith <[email protected]> > > To: > > "[email protected]" <[email protected]>, > > Date: > > 11/19/2013 08:58 PM > > Subject: > > [cxx-abi-dev] C++ ABI version 2 > > Sent by: > > [email protected] > > 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 > [email protected] > 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
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
