This is the mail archive of the
mailing list for the GCC project.
Re: Optimizing C++ Move Functions in Stl
- From: nick <xerofoify at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 11 Dec 2018 19:36:42 -0500
- Subject: Re: Optimizing C++ Move Functions in Stl
- References: <email@example.com> <20181211133704.GZ27131@redhat.com>
On 2018-12-11 8:37 a.m., Jonathan Wakely wrote:
> On 10/12/18 16:09 -0500, nick wrote:
>> Greetings All,
>> Sorry I was busy last week but did get my forms signed off for the
>> required copyright assignment. Anyhow seems that the tuple and other
>> classes mentioned aren't the only only ones that could do noexpect
>> optimization either for all cases or some in the header files.
>> I am proposing that I sent either a patch series or a patch per class
>> that actually could use this extension of the standard including the
>> string class I believe.
>> Not sure if this is a good idea but have opening it from discussion
>> for what classes should this touch in the std helper files,
> We'll consider any patches that add noexcept appropriately.
> It's not always worth doing though. For constructors it can matter,
> because it can affect the result of the is_nothrow_xxx_constructible
> traits, which can cause different code paths to be taken elsewhere in
> the library. For arbitrary member functions it doesn't usually make a
> difference. The compiler can already see that most inline functions
> can't throw, and so can already optimize accordingly.
> I suggest a series of patches, split along sensible lines (i.e. don't
> propose changes to unrelated types like std::basic_string and
> std::atomic in the same patch, which is always good advice anyway).
> Be aware that GCC is in Stage 3 of its development cycle, and changes
> like this which do not fix any bugs are probably going to have to wait
> for the next Stage 1. See https://gcc.gnu.org/develop.html#stage1 for
> more information.
Sorry for keeping this thread open. The only nit about your above comments related
to the inlining from assignment operators always is in the same boat if I understand
you then. This is probably the only member operator exception but it's basically
a constructor that returns something into another object so that's why.
Anyhow I cced the gcc development list but other than easy hacks are there any thing
you guys could use help with in stage 3?. I am assuming it's still another 2-3 months
before the final gcc 9 release and the above work should be submitted, so let me know
what's outstanding or needs help for moving along for the final gcc 9 release.
P.S. I was not aware of a TODO page for gcc 9 goals so if there is one as I googled for
one but couldn't find it, please just share that instead.