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.
