This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimizing C++ Move Functions in Stl



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.

Nick

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.  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]