This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 6 Feb 2019 15:12:29 +0200
- Subject: Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517
- References: <CAFk2RUaH6GRp_FqyHXPso_jy2WVdrc_QtdvWz=+9w5F-mBW93A@mail.gmail.com> <20190206101339.GA17805@redhat.com> <CAFk2RUbvq-DkELfhPuXLgqvHYiZN+t7uW23UW-pcY---+bpGYw@mail.gmail.com>
On Wed, 6 Feb 2019 at 12:21, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> > I think the assumption was this would produce smaller code. Does that
> > hold true?
>
> I think the assumption was that this produces equivalent or better
> code than fixing the current
> semantics bugs with some sort of separate constexpr arrays of function
> pointers would.
> And certainly better code than any approach that has a run-time
> branch. I don't think this ends up
> being different from the current codegen; both have an array indexing
> operation followed by an indirect
> function call.
And, to emphasize, the most important reason for this was to be able
to write straightforward
code for the special member functions, with the hope that it wouldn't
have a negative codegen
effect. Our Microsoft friends described the general technique as "has
crazy-good codegen",
but I have no idea what their starting point was; our starting point
probably wasn't bad
to begin with.