[Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly

[Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly

[blubban at gmail dot com]

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

            Bug ID: 115423
           Summary: Inlined strcmp optimizes poorly
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: blubban at gmail dot com
  Target Milestone: ---

bool g(const char* c) {
    return __builtin_strcmp(c, ".") == 0 ||
           __builtin_strcmp(c, "..") == 0;
}
bool h(const char* c) {
    return (c[0] == '.' && c[1] == '\0') ||
           (c[0] == '.' && c[1] == '.' && c[2] == '\0');
}


Compile with -O2.


Expected result: Same output from both.

Actual: The former results in a mess that, among other inefficiencies, loads
c[0] twice.


Online reproducer: https://godbolt.org/z/E4vEshvcM


(I don't know if this is an RTL or tree optimizer issue, I just guessed. Feel
free to move it if it's wrong.)

[Bug tree-optimization/115423] Inlined strcmp optimizes poorly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-11
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/115423] Inlined strcmp optimizes poorly

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
You could also say rtl-optimization does a bad job with the inlined version.
Or we should inline strcmp on GIMPLE to get the first char optimized.

Consider

 strcmp (c, "ABCDEFGHabcdefgh")
 || strcmp (c, "ABCDEFGHfoobar")

thus strings with a common prefix which we could optimize as

 strncmp (c, "ABCDEFGH", 8)
 && (strcmp (c+8, "abcdefgh")
     || strcmp (c+8, "foobar"))

as a more general transform.

I should say inline_string_cmp should consider using larger unaligned
reads as well.

[Bug tree-optimization/115423] Inlined strcmp optimizes poorly

[blubban at gmail dot com]

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

--- Comment #3 from Alfred Agrell <blubban at gmail dot com> ---
strcmp (c, "ABCDEFGHabcdefgh") || strcmp (c, "ABCDEFGHfoobar") can safely be
optimized to 1, you're thinking of strcmp(c, "ABCDEFGHabcdefgh")==0 ||
strcmp(c, "ABCDEFGHfoobar")==0.

Optimizing to multi-byte reads would be a wrong-code. If strcmp(c, "1234567")
does an eight-byte read, it'll segfault if c is {'e',0} four bytes before an
unmapped page.

Even if limiting it to aligned reads (can't segfault without crossing a page),
it'll annoy Valgrind.

(Large reads would be safe if lhs is char[8] and not char*, or if strlen is
checked before doing those reads, but both of those feel unlikely to me.)