[Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

[Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

[vittorio.romeo at outlook dot com]

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.

[Bug c++/107105] Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

[redi at gcc dot gnu.org]

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

[Bug c++/107105] Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

[pinskia at gcc dot gnu.org]

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.