public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity
@ 2024-02-07 12:34 rhalbersma at gmail dot com
2024-02-08 12:55 ` [Bug libstdc++/113807] " redi at gcc dot gnu.org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: rhalbersma at gmail dot com @ 2024-02-07 12:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
Bug ID: 113807
Summary: [performance] bitset::set not using memset opportunity
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rhalbersma at gmail dot com
Target Milestone: ---
Conditionally on is_constant_evaluated() being false, bitset::reset delegate to
__builtin_memset(_M_w, 0, _Nw * sizeof(_WordT)) and uses a loop otherwise. In
contrast, bitset::set unconditionally has a raw loop.
Can't bitset::set also not similarly use __builtin_memset(_M_w, 0xFF, _Nw *
sizeof(_WordT)); when is_constant_evaluated() is false?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
@ 2024-02-08 12:55 ` redi at gcc dot gnu.org
2024-02-15 11:44 ` cvs-commit at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-08 12:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-02-08
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yup, I don't see why not.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
2024-02-08 12:55 ` [Bug libstdc++/113807] " redi at gcc dot gnu.org
@ 2024-02-15 11:44 ` cvs-commit at gcc dot gnu.org
2024-02-15 11:53 ` rhalbersma at gmail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-02-15 11:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:e7ae13a858f36031b8fd3aa07362752ff2b19b2e
commit r14-9002-ge7ae13a858f36031b8fd3aa07362752ff2b19b2e
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Feb 8 15:46:08 2024 +0000
libstdc++: Use memset to optimize std::bitset::set() [PR113807]
As pointed out in the PR we already do this for reset().
libstdc++-v3/ChangeLog:
PR libstdc++/113807
* include/std/bitset (bitset::set()): Use memset instead of a
loop over the individual words.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
2024-02-08 12:55 ` [Bug libstdc++/113807] " redi at gcc dot gnu.org
2024-02-15 11:44 ` cvs-commit at gcc dot gnu.org
@ 2024-02-15 11:53 ` rhalbersma at gmail dot com
2024-02-15 12:40 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rhalbersma at gmail dot com @ 2024-02-15 11:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
--- Comment #3 from rhalbersma <rhalbersma at gmail dot com> ---
Nice that this is changed now. I noticed a similar optimization could be done
for bitset::operator== (more accurately: the helper _M_is_equal) where there is
an opportunity to use memcmp, with a similar dance for consteval contexts. MSVC
STL also does this.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (2 preceding siblings ...)
2024-02-15 11:53 ` rhalbersma at gmail dot com
@ 2024-02-15 12:40 ` redi at gcc dot gnu.org
2024-02-15 12:45 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-15 12:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm surprised the compiler can't optimize _M_do_set() and operator== already,
but it looks like it doesn't recognize the trivial loops.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (3 preceding siblings ...)
2024-02-15 12:40 ` redi at gcc dot gnu.org
@ 2024-02-15 12:45 ` jakub at gcc dot gnu.org
2024-02-15 12:51 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-15 12:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For
unsigned int a[1024];
void
foo (void)
{
for (int i = 0; i < 1024; ++i)
a[i] = 0;
}
void
bar (void)
{
for (int i = 0; i < 1024; ++i)
a[i] = -1;
}
it certainly can.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (4 preceding siblings ...)
2024-02-15 12:45 ` jakub at gcc dot gnu.org
@ 2024-02-15 12:51 ` rguenth at gcc dot gnu.org
2024-02-15 13:10 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-02-15 12:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
It can also for an effective memset to a non-constant, but it has to be
uniform,
thus 'char'.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (5 preceding siblings ...)
2024-02-15 12:51 ` rguenth at gcc dot gnu.org
@ 2024-02-15 13:10 ` redi at gcc dot gnu.org
2024-02-15 13:36 ` rhalbersma at gmail dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-15 13:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Hmm, yes, the code for bitset<N>::set() is actually similar to what we get for
foo() in comment 5. The new version with memset does produce different
(vectorized?) code though.
For operator== the current code is quite branchy, and looks better with memcmp
to me (but I don't really know what I'm talking about).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (6 preceding siblings ...)
2024-02-15 13:10 ` redi at gcc dot gnu.org
@ 2024-02-15 13:36 ` rhalbersma at gmail dot com
2024-02-15 13:43 ` redi at gcc dot gnu.org
2024-05-07 7:44 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rhalbersma at gmail dot com @ 2024-02-15 13:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
--- Comment #8 from rhalbersma <rhalbersma at gmail dot com> ---
For bitset::operator==, I wonder why (at last in C++20 and later mode) it is
not defaulted?
For bitset::set and bitset::operator==, I also wonder why the manual loop vs
memset/memcmp consteval logic is not delegated to a call of std::fill_n or
std::equal, respectively? Then std::bitset is better proofed against future
changes in the tradeoffs between manual loops, unrolled loops or library calls,
no?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (7 preceding siblings ...)
2024-02-15 13:36 ` rhalbersma at gmail dot com
@ 2024-02-15 13:43 ` redi at gcc dot gnu.org
2024-05-07 7:44 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-15 13:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to rhalbersma from comment #8)
> For bitset::operator==, I wonder why (at last in C++20 and later mode) it is
> not defaulted?
Because nobody bothered to change working code.
> For bitset::set and bitset::operator==, I also wonder why the manual loop vs
> memset/memcmp consteval logic is not delegated to a call of std::fill_n or
> std::equal, respectively?
Those aren't constexpr in C++14, but bitset is. If we delegated to those algos
we'd still need a constexpr-in-C++14 manual loop.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug libstdc++/113807] [performance] bitset::set not using memset opportunity
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
` (8 preceding siblings ...)
2024-02-15 13:43 ` redi at gcc dot gnu.org
@ 2024-05-07 7:44 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113807
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.0 |14.2
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2024-05-07 7:44 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-07 12:34 [Bug libstdc++/113807] New: [performance] bitset::set not using memset opportunity rhalbersma at gmail dot com
2024-02-08 12:55 ` [Bug libstdc++/113807] " redi at gcc dot gnu.org
2024-02-15 11:44 ` cvs-commit at gcc dot gnu.org
2024-02-15 11:53 ` rhalbersma at gmail dot com
2024-02-15 12:40 ` redi at gcc dot gnu.org
2024-02-15 12:45 ` jakub at gcc dot gnu.org
2024-02-15 12:51 ` rguenth at gcc dot gnu.org
2024-02-15 13:10 ` redi at gcc dot gnu.org
2024-02-15 13:36 ` rhalbersma at gmail dot com
2024-02-15 13:43 ` redi at gcc dot gnu.org
2024-05-07 7:44 ` rguenth at gcc dot gnu.org
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).