From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: Jonathan Wakely <jwakely@redhat.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
"libstdc++" <libstdc++@gcc.gnu.org>
Subject: Re: [PATCH v2] libstdc++: optimize bit iterators assuming normalization [PR110807]
Date: Thu, 9 Nov 2023 01:22:13 +0000 [thread overview]
Message-ID: <CAH6eHdSknFCEqo+EtuLQFkw_CeO+dOd3GM=vKO4JgAN2ryKn7g@mail.gmail.com> (raw)
In-Reply-To: <ormsvnhgj2.fsf_-_@lxoliva.fsfla.org>
[-- Attachment #1: Type: text/plain, Size: 11089 bytes --]
On Thu, 9 Nov 2023, 01:17 Alexandre Oliva, <oliva@adacore.com> wrote:
> On Nov 8, 2023, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> > A single underscore prefix on __GLIBCXX_BUILTIN_ASSUME and
> > __GLIBCXX_DISABLE_ASSUMPTIONS please.
>
> That's entirely gone now.
>
> >> + do \
> >> + if (std::is_constant_evaluated ()) \
> >> + static_assert(expr); \
>
> > This can never be valid.
>
> *nod*
>
> > This already works fine in constant evaluation anyway.
>
> Yeah, that's what I figured.
>
> > But what's the null dereference for?
>
> The idea was to clearly trigger undefined behavior. Maybe it wasn't
> needed, it didn't occur to me that __builtin_unreachable() would be
> enough. I realize I was really trying to emulate attribute assume, even
> without knowing it existed ;-)
>
> >> +#define __GLIBCXX_BUILTIN_ASSUME(expr) \
> >> + (void)(false && (expr))
>
> > What's the point of this, just to verify that (expr) is contextually
> > convertible to bool?
>
> I'd have phrased it as "avoid the case in which something compiles with
> -O0 but not with -O", but yeah ;-)
>
> > We don't use the _p suffix for predicates in the library.
> > Please use just _M_normalized or _M_is_normalized.
>
> ACK. It's also gone now.
>
> > But do we even need this function? It's not used anywhere else, can we
> > just inline the condition into _M_assume_normalized() ?
>
> I had other uses for it in earlier versions of the patch, but it makes
> no sense any more indeed.
>
> >> + _GLIBCXX20_CONSTEXPR
> >> + void
> >> + _M_assume_normalized() const
>
> > I think this should use _GLIBCXX_ALWAYS_INLINE
>
> *nod*, thanks
>
> >> + {
> >> + __GLIBCXX_BUILTIN_ASSUME (_M_normalized_p ());
>
> > Is there even any benefit to this macro?
>
> I just thought it could have other uses, without being aware that the
> entire concept was available as a statement attribute. Funny, I'd even
> searched for it among the existing attributes and builtins, but somehow
> I managed to miss it. Thanks for getting me back down that path.
>
> > __attribute__((__assume__(_M_offset < unsigned(_S_word_bit))));
>
> That unfortunately doesn't work, because the assume lowering doesn't go
> as far as dereferencing the implicit this and making an SSA_NAME out of
> the loaded _M_offset, which we'd need to be able to optimize based on
> it. But that only took me a while to figure out and massage into
> something that had the desired effect. Now, maybe the above *should*
> have that effect already, but unfortunately it doesn't.
>
> > Maybe even get rid of _M_assume_normalized() as a function and just
> > put that attribute everywhere you currently use _M_assume_normalized.
>
> Because of the slight kludge required to make the attribute have the
> desired effect (namely ensuring the _M_offset reference is evaluated),
> I've retained it as an inline function.
>
> Here's what I'm retesting now. WDYT?
>
ofst needs to be __ofst but OK for trunk with that change.
We probably want this on the gcc-13 branch too, but let's give it some time
on trunk in case the assume attribute isn't quite ready for prime time.
>
> libstdc++: optimize bit iterators assuming normalization [PR110807]
>
> The representation of bit iterators, using a pointer into an array of
> words, and an unsigned bit offset into that word, makes for some
> optimization challenges: because the compiler doesn't know that the
> offset is always in a certain narrow range, beginning at zero and
> ending before the word bitwidth, when a function loads an offset that
> it hasn't normalized itself, it may fail to derive certain reasonable
> conclusions, even to the point of retaining useless calls that elicit
> incorrect warnings.
>
> Case at hand: The 110807.cc testcase for bit vectors assigns a 1-bit
> list to a global bit vector variable. Based on the compile-time
> constant length of the list, we decide in _M_insert_range whether to
> use the existing storage or to allocate new storage for the vector.
> After allocation, we decide in _M_copy_aligned how to copy any
> preexisting portions of the vector to the newly-allocated storage.
> When copying two or more words, we use __builtin_memmove.
>
> However, because we compute the available room using bit offsets
> without range information, even comparing them with constants, we fail
> to infer ranges for the preexisting vector depending on word size, and
> may thus retain the memmove call despite knowing we've only allocated
> one word.
>
> Other parts of the compiler then detect the mismatch between the
> constant allocation size and the much larger range that could
> theoretically be copied into the newly-allocated storage if we could
> reach the call.
>
> Ensuring the compiler is aware of the constraints on the offset range
> enables it to do a much better job at optimizing. Using attribute
> assume (_M_offset <= ...) didn't work, because gimple lowered that to
> something that vrp could only use to ensure 'this' was non-NULL.
> Exposing _M_offset as an automatic variable/gimple register outside
> the unevaluated assume operand enabled the optimizer to do its job.
>
> Rather than placing such load-then-assume constructs all over, I
> introduced an always-inline member function in bit iterators that does
> the job of conveying to the compiler the information that the
> assumption is supposed to hold, and various calls throughout functions
> pertaining to bit iterators that might not otherwise know that the
> offsets have to be in range, so that the compiler no longer needs to
> make conservative assumptions that prevent optimizations.
>
> With the explicit assumptions, the compiler can correlate the test for
> available storage in the vector with the test for how much storage
> might need to be copied, and determine that, if we're not asking for
> enough room for two or more words, we can omit entirely the code to
> copy two or more words, without any runtime overhead whatsoever: no
> traces remain of the undefined behavior or of the tests that inform
> the compiler about the assumptions that must hold.
>
>
> for libstdc++-v3/ChangeLog
>
> PR libstdc++/110807
> * include/bits/stl_bvector.h (_Bit_iterator_base): Add
> _M_assume_normalized member function. Call it in _M_bump_up,
> _M_bump_down, _M_incr, operator==, operator<=>, operator<, and
> operator-.
> (_Bit_iterator): Also call it in operator*.
> (_Bit_const_iterator): Likewise.
> ---
> libstdc++-v3/include/bits/stl_bvector.h | 37
> ++++++++++++++++++++++++++++---
> 1 file changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/stl_bvector.h
> b/libstdc++-v3/include/bits/stl_bvector.h
> index 8d18bcaffd434..bb9f38cdf2d59 100644
> --- a/libstdc++-v3/include/bits/stl_bvector.h
> +++ b/libstdc++-v3/include/bits/stl_bvector.h
> @@ -56,6 +56,10 @@
> #ifndef _STL_BVECTOR_H
> #define _STL_BVECTOR_H 1
>
> +#ifndef _GLIBCXX_ALWAYS_INLINE
> +#define _GLIBCXX_ALWAYS_INLINE inline __attribute__((__always_inline__))
> +#endif
> +
> #if __cplusplus >= 201103L
> #include <initializer_list>
> #include <bits/functional_hash.h>
> @@ -177,6 +181,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> _Bit_type * _M_p;
> unsigned int _M_offset;
>
> + _GLIBCXX20_CONSTEXPR _GLIBCXX_ALWAYS_INLINE
> + void
> + _M_assume_normalized() const
> + {
> + unsigned int ofst = _M_offset;
> + __attribute__ ((__assume__ (ofst < unsigned(_S_word_bit))));
> + }
> +
> _GLIBCXX20_CONSTEXPR
> _Bit_iterator_base(_Bit_type * __x, unsigned int __y)
> : _M_p(__x), _M_offset(__y) { }
> @@ -185,6 +197,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> void
> _M_bump_up()
> {
> + _M_assume_normalized();
> if (_M_offset++ == int(_S_word_bit) - 1)
> {
> _M_offset = 0;
> @@ -196,6 +209,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> void
> _M_bump_down()
> {
> + _M_assume_normalized();
> if (_M_offset-- == 0)
> {
> _M_offset = int(_S_word_bit) - 1;
> @@ -207,6 +221,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> void
> _M_incr(ptrdiff_t __i)
> {
> + _M_assume_normalized();
> difference_type __n = __i + _M_offset;
> _M_p += __n / int(_S_word_bit);
> __n = __n % int(_S_word_bit);
> @@ -221,7 +236,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> _GLIBCXX_NODISCARD
> friend _GLIBCXX20_CONSTEXPR bool
> operator==(const _Bit_iterator_base& __x, const _Bit_iterator_base&
> __y)
> - { return __x._M_p == __y._M_p && __x._M_offset == __y._M_offset; }
> + {
> + __x._M_assume_normalized();
> + __y._M_assume_normalized();
> + return __x._M_p == __y._M_p && __x._M_offset == __y._M_offset;
> + }
>
> #if __cpp_lib_three_way_comparison
> [[nodiscard]]
> @@ -229,6 +248,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> operator<=>(const _Bit_iterator_base& __x, const _Bit_iterator_base&
> __y)
> noexcept
> {
> + __x._M_assume_normalized();
> + __y._M_assume_normalized();
> if (const auto __cmp = __x._M_p <=> __y._M_p; __cmp != 0)
> return __cmp;
> return __x._M_offset <=> __y._M_offset;
> @@ -238,6 +259,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> friend bool
> operator<(const _Bit_iterator_base& __x, const _Bit_iterator_base&
> __y)
> {
> + __x._M_assume_normalized();
> + __y._M_assume_normalized();
> return __x._M_p < __y._M_p
> || (__x._M_p == __y._M_p && __x._M_offset < __y._M_offset);
> }
> @@ -266,6 +289,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> friend _GLIBCXX20_CONSTEXPR ptrdiff_t
> operator-(const _Bit_iterator_base& __x, const _Bit_iterator_base&
> __y)
> {
> + __x._M_assume_normalized();
> + __y._M_assume_normalized();
> return (int(_S_word_bit) * (__x._M_p - __y._M_p)
> + __x._M_offset - __y._M_offset);
> }
> @@ -297,7 +322,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
> reference
> operator*() const
> - { return reference(_M_p, 1UL << _M_offset); }
> + {
> + _M_assume_normalized();
> + return reference(_M_p, 1UL << _M_offset);
> + }
>
> _GLIBCXX20_CONSTEXPR
> iterator&
> @@ -408,7 +436,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
> const_reference
> operator*() const
> - { return _Bit_reference(_M_p, 1UL << _M_offset); }
> + {
> + _M_assume_normalized();
> + return _Bit_reference(_M_p, 1UL << _M_offset);
> + }
>
> _GLIBCXX20_CONSTEXPR
> const_iterator&
>
>
> --
> Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
> Free Software Activist GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>
next prev parent reply other threads:[~2023-11-09 1:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 16:10 [PATCH] " Alexandre Oliva
2023-11-08 19:32 ` Jonathan Wakely
2023-11-09 1:17 ` [PATCH v2] " Alexandre Oliva
2023-11-09 1:22 ` Jonathan Wakely [this message]
2023-11-09 3:36 ` [PATCH v3] " Alexandre Oliva
2023-11-09 5:57 ` François Dumont
2023-11-09 8:16 ` Jonathan Wakely
2023-11-09 19:49 ` [PATCH] libstdc++: bvector: undef always_inline macro Alexandre Oliva
2023-11-09 20:18 ` Jonathan Wakely
2023-11-15 2:20 ` Patrick Palka
2023-11-15 5:53 ` Alexandre Oliva
2023-11-15 2:44 ` Alexandre Oliva
2023-11-15 5:08 ` Alexandre Oliva
2023-11-15 8:22 ` Jonathan Wakely
2023-11-16 4:40 ` Alexandre Oliva
2024-02-07 16:25 ` [PATCH v2] libstdc++: optimize bit iterators assuming normalization [PR110807] Torbjorn SVENSSON
2024-02-07 16:36 ` Jonathan Wakely
2024-02-09 8:49 ` Torbjorn SVENSSON
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='CAH6eHdSknFCEqo+EtuLQFkw_CeO+dOd3GM=vKO4JgAN2ryKn7g@mail.gmail.com' \
--to=jwakely.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
--cc=oliva@adacore.com \
/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).