public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level
@ 2022-09-30 19:10 vittorio.romeo at outlook dot com
2022-09-30 19:31 ` [Bug c++/107105] " redi at gcc dot gnu.org
2024-04-13 1:30 ` pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: vittorio.romeo at outlook dot com @ 2022-09-30 19:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107105
Bug ID: 107105
Summary: Consider folding `__and_`, `__or_`, and `__not_` at
the front-end level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
This is another possible compilation speed improvement that came to mind after
running ClangBuildAnalyzer on a few open source projects (gzdoom, SFML, some of
my own, ...) and noticing results like these:
**** Template sets that took longest to instantiate:
35407 ms: std::__and_<$> (20262 times, avg 1 ms)
17745 ms: std::unique_ptr<$> (916 times, avg 19 ms)
14302 ms: std::__uniq_ptr_data<$> (916 times, avg 15 ms)
14153 ms: std::__uniq_ptr_impl<$> (916 times, avg 15 ms)
13537 ms: std::__or_<$> (15100 times, avg 0 ms)
13046 ms: std::basic_string<$> (2248 times, avg 5 ms)
11706 ms: std::_Hashtable<$> (1051 times, avg 11 ms)
10527 ms: std::unordered_map<$> (545 times, avg 19 ms)
10379 ms: std::is_convertible<$> (11737 times, avg 0 ms)
It looks like `__and_`, `__or_`, and `__not_` are widely used throughout
libstdc++'s implementation, and are used to implement most type traits.
I was wondering whether it would be possible and somewhat easy to fold these in
the front-end, similarly to what has been done for `std::move` and similar
functions. Another option is to use a compiler intrinsic.
I have not done any research, but I suppose that if this is possible, reducing
the number of instantiations of these small helpers would benefit pretty much
every project using libstdc++. Just an idea -- feel free to close this ticket
if this is not possible or not worth the effort.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/107105] Consider folding `__and_`, `__or_`, and `__not_` at the front-end level
2022-09-30 19:10 [Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level vittorio.romeo at outlook dot com
@ 2022-09-30 19:31 ` redi at gcc dot gnu.org
2024-04-13 1:30 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-30 19:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107105
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2022-09-30
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You didn't set the Version field, so I don't know what GCC version your results
are from. I assume you're not using GCC trunk and don't have this patch:
commit g:390f94eee1ae694901f896ac45bfb148f8126baa
Author: Patrick Palka
Date: Fri Aug 26 20:10:57 2022
libstdc++: Optimize std::con/disjunction, __and_/__or_, etc
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c++/107105] Consider folding `__and_`, `__or_`, and `__not_` at the front-end level
2022-09-30 19:10 [Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level vittorio.romeo at outlook dot com
2022-09-30 19:31 ` [Bug c++/107105] " redi at gcc dot gnu.org
@ 2024-04-13 1:30 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-13 1:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107105
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Target Milestone|--- |13.0
Status|WAITING |RESOLVED
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So fixed.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-13 1:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-30 19:10 [Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level vittorio.romeo at outlook dot com
2022-09-30 19:31 ` [Bug c++/107105] " redi at gcc dot gnu.org
2024-04-13 1:30 ` pinskia 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).