From: Jonathan Wakely <jwakely@redhat.com>
To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Cc: Axel Naumann <Axel.Naumann@cern.ch>, Tim Adye <Tim.Adye@cern.ch>
Subject: Re: [committed] libstdc++: Optimize std::any_cast by replacing indirect call
Date: Fri, 4 Jun 2021 18:05:42 +0100 [thread overview]
Message-ID: <YLpdZobckn5WaUH3@redhat.com> (raw)
In-Reply-To: <YLpcql5V21/vkE5o@redhat.com>
Apparently my mailer decided to sent this email as From: Tim, rather
than me. Sorry for any confusion. The patch is from Tim, but the
email to the lists was sent by me (jwakely). Hopefully this one will
have the right From: header on it!
On 04/06/21 18:02 +0100, Tim Adye wrote:
>This significantly improves the performance of std::any_cast, by
>avoiding an indirect call to the _S_manage function through a function
>pointer. Before we make that indirect call we've already established
>that the contained value has the expected type, which means we also know
>the manager type, and so can call one of its members directly.
>
>We also know the precise type in the any::emplace functions, because
>we've just constructed that type, so we can use the new member there
>too. That doesn't seem to affect performance, but we might as well use
>the new _S_access function anyway.
>
>Signed-off-by: Tim Adye <Tim.Adye@cern.ch>
>Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
>
>libstdc++-v3/ChangeLog:
>
> * include/std/any (any::_Manager::_S_access): New static
> function to access the contained value.
> (any::emplace, __any_caster): Use _S_access member of the
> manager type.
>
>Tested powerpc64le-linux. Committed to trunk.
>
>This patch was contributed by Tim Adye and accepted in line with the
>new policy announced in https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
>
>Thanks, Tim!
>
>commit f6bb145c0bff19767931d37733be11c8acc6fa00
>Author: Tim Adye <Tim.Adye@cern.ch>
>Date: Fri Jun 4 15:59:38 2021
>
> libstdc++: Optimize std::any_cast by replacing indirect call
>
> This significantly improves the performance of std::any_cast, by
> avoiding an indirect call to the _S_manage function through a function
> pointer. Before we make that indirect call we've already established
> that the contained value has the expected type, which means we also know
> the manager type, and so can call one of its members directly.
>
> We also know the precise type in the any::emplace functions, because
> we've just constructed that type, so we can use the new member there
> too. That doesn't seem to affect performance, but we might as well use
> the new _S_access function anyway.
>
> Signed-off-by: Tim Adye <Tim.Adye@cern.ch>
> Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
>
> libstdc++-v3/ChangeLog:
>
> * include/std/any (any::_Manager::_S_access): New static
> function to access the contained value.
> (any::emplace, __any_caster): Use _S_access member of the
> manager type.
>
>diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
>index 391e43339a0..21120a9146f 100644
>--- a/libstdc++-v3/include/std/any
>+++ b/libstdc++-v3/include/std/any
>@@ -263,9 +263,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> {
> using _VTp = decay_t<_Tp>;
> __do_emplace<_VTp>(std::forward<_Args>(__args)...);
>- any::_Arg __arg;
>- this->_M_manager(any::_Op_access, this, &__arg);
>- return *static_cast<_VTp*>(__arg._M_obj);
>+ return *any::_Manager<_VTp>::_S_access(_M_storage);
> }
>
> /// Emplace with an object created from @p __il and @p __args as
>@@ -276,9 +274,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> {
> using _VTp = decay_t<_Tp>;
> __do_emplace<_VTp, _Up>(__il, std::forward<_Args>(__args)...);
>- any::_Arg __arg;
>- this->_M_manager(any::_Op_access, this, &__arg);
>- return *static_cast<_VTp*>(__arg._M_obj);
>+ return *any::_Manager<_VTp>::_S_access(_M_storage);
> }
>
> // modifiers
>@@ -384,6 +380,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> void* __addr = &__storage._M_buffer;
> ::new (__addr) _Tp(std::forward<_Args>(__args)...);
> }
>+
>+ static _Tp*
>+ _S_access(const _Storage& __storage)
>+ {
>+ // The contained object is in __storage._M_buffer
>+ const void* __addr = &__storage._M_buffer;
>+ return static_cast<_Tp*>(const_cast<void*>(__addr));
>+ }
> };
>
> // Manage external contained object.
>@@ -405,6 +409,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> {
> __storage._M_ptr = new _Tp(std::forward<_Args>(__args)...);
> }
>+ static _Tp*
>+ _S_access(const _Storage& __storage)
>+ {
>+ // The contained object is in *__storage._M_ptr
>+ return static_cast<_Tp*>(__storage._M_ptr);
>+ }
> };
> };
>
>@@ -511,9 +521,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> #endif
> )
> {
>- any::_Arg __arg;
>- __any->_M_manager(any::_Op_access, __any, &__arg);
>- return __arg._M_obj;
>+ return any::_Manager<_Up>::_S_access(__any->_M_storage);
> }
> return nullptr;
> }
prev parent reply other threads:[~2021-06-04 17:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 17:02 Tim Adye
2021-06-04 17:05 ` Jonathan Wakely [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YLpdZobckn5WaUH3@redhat.com \
--to=jwakely@redhat.com \
--cc=Axel.Naumann@cern.ch \
--cc=Tim.Adye@cern.ch \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).