[Bug tree-optimization/102958] std::u8string suboptimal compared to std::string

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org,
                   |                            |jwakely.gcc at gmail dot com
            Summary|std::u8string suboptimal    |std::u8string suboptimal
                   |compared to std::string,    |compared to std::string
                   |triggers warnings           |

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Adjusting description, since not only have we disabled the warning in the C++
headers so this no longer warns, but the underlying problem has nothing to do
with warnings.

The char_traits<char8_t> specialization is opaque enough such that we can't
figure out the length:

      static _GLIBCXX17_CONSTEXPR size_t
      length(const char_type* __s)
      {
#if __cplusplus >= 201703L
        if (std::__is_constant_evaluated())
          return __gnu_cxx::char_traits<char_type>::length(__s);
#endif
        size_t __i = 0;
        while (!eq(__s[__i], char_type()))
          ++__i;
        return __i;
      }

OTOH, the <char> specialization falls back to a __builtin_strlen which which is
trivial to see through.

I think this boils down to pinski's comment that we fail to see a string length
calculation in the following sequence, which survives all the way to the
.optimized dump:

  <bb 3> [local count: 8687547538]:
  # __i_46 = PHI <__i_22(3), 0(2)>
  __i_22 = __i_46 + 1;
  _24 = MEM[(const char_type &)"123456789" + __i_22 * 1];
  if (_24 != 0)
    goto <bb 3>; [89.00%]
  else
    goto <bb 4>; [11.00%]

I've seen variations of the above being turned into __builtin_strlen by fre,
ldist, as well as the strlen [ass.  Who's job is it perform this optimization?