[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.