[Bug rtl-optimization/110163] New: [14 Regression] Comparing against a constant string is inefficient on some targets

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

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

            Bug ID: 110163
           Summary: [14 Regression] Comparing against a constant string is
                    inefficient on some targets
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Comparing against a constant string is expanded by inline_string_cmp and on
some targets the generated code can be inefficient.  This can be seen in
spec2017's omnetpp benchmark, particularly when the inline string comparison
limits are increased.

The problem is the expansion code arranges to do all the arithmetic and tests
in SImode.  On RV64 this introduces a sign extension for each test  due to how
RV64 expresses 32bit ops.

It would be better to do all the computations in word_mode, then convert the
final result to SImode, at least for RV64 and likely for other targets.

I experimented with starting to build out cost checks to determine what mode to
use for the internal computations.  That ran afoul of x86 where the cost of a
byte load is different than the cost of an extended byte load, even though they
use the exact same instruction.

There's also a need to cost out the computations, test & branch in the
different modes as well once the x86 hurdle is behind us.

I've set work on this aside for now.  But the discussion can be found in these
two threads:

https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620601.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620577.html

#include <string.h>
int
foo (char *x)
{
   return strcmp (x, "lowerLayout");
}

Compiled with -O2 --param builtin-string-cmp-inline-length=100 on rv64 should
show the issue.