[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #11 from Niels Möller --- Here's a bit more docs on using std::unique_ptr [[clang::trivial_abi]] with clang and its C++ library. https://libcxx.llvm.org//DesignDocs/UniquePtrTrivialAbi.html As for "No, it needs co-operation between G++ and all other compilers using the same ABI", I would think that if gcc and clang could agree, others would start moving.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #10 from Niels Möller --- I was just made aware of this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf arguing that C++ standards community and implementers ought to decide on how to prioritize C++ performance vs ABI stability. Passing unique_ptr is one if the items mentioned.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #9 from Marc Glisse --- (In reply to Jonathan Wakely from comment #8) > you'd still need a change to the Itanium ABI. Or an attribute like [[clang::trivial_abi]], or the one that p1029 is trying to standardize. But since we would need all compilers to support the attribute, I guess that it would indeed count as a change to the Itanium ABI.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #8 from Jonathan Wakely --- Yes, when configured with --enable-symvers=gnu-versioned-namespace But that's just for the library, you'd still need a change to the Itanium ABI.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #7 from Marc Glisse --- (In reply to Jonathan Wakely from comment #6) > libstdc++ would not take > advantage of it because it would break the library's stable ABI. There is always this mode (is it _GLIBCXX_INLINE_VERSION? I thought I remembered a different name) that nobody uses, that doesn't care about binary compatibility, but can be used to experiment...
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #6 from Jonathan Wakely --- No, it needs co-operation between G++ and all other compilers using the same ABI, which makes it out of scope for GCC's bugzilla. G++ cannot unilaterally change the ABI here, and even if we could, libstdc++ would not take advantage of it because it would break the library's stable ABI. So WONTFIX.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #5 from Niels Möller --- (In reply to Jonathan Wakely from comment #4) > Why wouldn't you take unique_ptr&& instead of passing by value? Because passing unique_ptr (and other move-only types) by value seems to be the mainstream idiomatic way to pass around ownership in C++. I'm confident I could save 0.05% binary size on webrtc's AppRTCMobile.apk by passing unique_ptr&& everywhere. But my closest C++ experts consider that not a good enough reason to depart from the more mainstream idiom, and I think they have a good point. Maybe it's a revival of the old Lisp tradition to write code for clarity, and in case the compiler generates poor code, just put your faith in future compiler improvements. > I'm closing this bug, as there's nothing libstdc++ can do here. Any improvement needs cooperation between g++ and libstdc++; I was hoping this bug report would reach relevant people involved on both sides.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Jonathan Wakely --- (In reply to Niels Möller from comment #2) > My impression was that C++ ABI is under the control of compiler and C++ > standard library, and that there is no such thing as a standard C++ ABI. See http://itanium-cxx-abi.github.io/cxx-abi/ > For specific types defined by the GNU standard C++ library, it may also be > possible to add any needed G++ specific attributes in library headers to > tell the compiler to depart from the "standard" ABI. Not without changing the existing ABI. > > In any case, how common is it to have a pointless non-inline baz function > > which does nothing but forward to another non-inline function? > > In my experience (mainly from working on the webrtc.org code, where > implementation inheritance is discouraged), it's common with implementations > of interface classes consisting of almost trivial implementations of the > interface's virtual functions, which only setup the correct arguments for > calling a non-inlined (and possibly virtual) method on some member to do the > real work. Why wouldn't you take unique_ptr&& instead of passing by value? I'm closing this bug, as there's nothing libstdc++ can do here.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #3 from Marc Glisse --- (In reply to Niels Möller from comment #2) > (In reply to Jonathan Wakely from comment #1) > > The ABI dictates the calling conventions and there's certainly nothing that > > libstdc++ can do about it. > > My impression was that C++ ABI is under the control of compiler and C++ > standard library, and that there is no such thing as a standard C++ ABI. Most compilers (not all, in particular not Microsoft) use the strangely named Itanium C++ ABI. > As evidenced by the (rare) ABI breaks in libstdc++, and the difficulty of > linking C++ objects compiled with different C++ compilers (e.g, g++ and > clang++). It is an ABI for the language, not the library. g++ and clang++ are supposed to be compatible, as long as you use the same standard library for both. > So if > it's really not feasible to improve the situation at all for gnu/linux > x86_64 elf targets, *please* try to keep std::unique_ptr in mind when > involved in ABI design for other targets. There are indeed sometimes discussions about a V2 of the ABI, for new targets or those that can afford to break ABI compatibility. > For specific types defined by the GNU standard C++ library, it may also be > possible to add any needed G++ specific attributes in library headers to > tell the compiler to depart from the "standard" ABI. clang has such an attribute [[clang::trivial_abi]], p1029 is trying to standardize it. But adding it in the library now would be an ABI break, which the maintainers are strongly opposed to :-( > In my experience (mainly from working on the webrtc.org code, where > implementation inheritance is discouraged), it's common with implementations > of interface classes consisting of almost trivial implementations of the > interface's virtual functions, which only setup the correct arguments for > calling a non-inlined (and possibly virtual) method on some member to do the > real work. virtual doesn't always prevent inlining (but it often does indeed).
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #2 from Niels Möller --- (In reply to Jonathan Wakely from comment #1) > The ABI dictates the calling conventions and there's certainly nothing that > libstdc++ can do about it. My impression was that C++ ABI is under the control of compiler and C++ standard library, and that there is no such thing as a standard C++ ABI. As evidenced by the (rare) ABI breaks in libstdc++, and the difficulty of linking C++ objects compiled with different C++ compilers (e.g, g++ and clang++). If ABI standard + language spec nails down, e.g., rules on when to pass a C++ object by invisible reference, but doesn't nail down the ABI of std::string, then the C++ specifics of the ABI standard is a bit pointless, imo. But I understand my opinion doesn't carry much weight on that... So if it's really not feasible to improve the situation at all for gnu/linux x86_64 elf targets, *please* try to keep std::unique_ptr in mind when involved in ABI design for other targets. For specific types defined by the GNU standard C++ library, it may also be possible to add any needed G++ specific attributes in library headers to tell the compiler to depart from the "standard" ABI. > In any case, how common is it to have a pointless non-inline baz function > which does nothing but forward to another non-inline function? In my experience (mainly from working on the webrtc.org code, where implementation inheritance is discouraged), it's common with implementations of interface classes consisting of almost trivial implementations of the interface's virtual functions, which only setup the correct arguments for calling a non-inlined (and possibly virtual) method on some member to do the real work.
[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356 --- Comment #1 from Jonathan Wakely --- The ABI dictates the calling conventions and there's certainly nothing that libstdc++ can do about it. In any case, how common is it to have a pointless non-inline baz function which does nothing but forward to another non-inline function? In practice the callers of baz will be able to inline it, removing unnecessary null checks on the moved-from variable, or baz will be able to inline bar, removing the temporary entirely.
