This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Antony Polukhin <antoshkka at gmail dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Ville Voutilainen <ville dot voutilainen at gmail dot com>, Tim Shen <timshen91 at gmail dot com>
- Date: Wed, 3 Apr 2019 23:27:26 +0100
- Subject: Re: [PATCH] PR libstdc++/87431 re-adjust never-valueless optimizations
- References: <20190403162543.GO943@redhat.com> <CAKqmYPY-r3z4hk0jG208qjPy+ZADcupvy2rsiGWNMqrMmQ-n1g@mail.gmail.com>
On 03/04/19 23:32 +0300, Antony Polukhin wrote:
Looks good. Covers most of the use cases.
Please consider adding filesystem::path, pair, tuple, string_view?,
string_view is trivially_copyable, and < 256 bytes, so works
automatically.
error_code, list, deque (myabe all the other containers), optional, variant
itself (for cases when variant holds another variant).
I hadn't thought about error_code and recursive variants, I'll check
those can be made to work.
filesystem::path had occurred to me, but I'm undecided.
pair, tuple and optional I think can be done as shown in my email.
It would be very useful for the _Never_valueless_alt to return true for
aggregates that hold only never valueles types. Not sure that there is a
compiler builtin for getting all the aggregates types, but it could be
implemented via metaprogramming.
Useful, but not essential.
This is a Quality of Implementation issue, and the cases where an
exception actually gets thrown and leaves the variant valueless are
going to be rare anyway. The codegen benefits of being never-valueless
are minor.
So I don't think we need to go too wild doing this.
When is the ABI freeze for the C++17 additions?
The GCC 9 release, ideally.