public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly
@ 2024-06-11 0:08 blubban at gmail dot com
2024-06-11 4:24 ` [Bug tree-optimization/115423] " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: blubban at gmail dot com @ 2024-06-11 0:08 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/115423] Inlined strcmp optimizes poorly
2024-06-11 0:08 [Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly blubban at gmail dot com
@ 2024-06-11 4:24 ` pinskia at gcc dot gnu.org
2024-06-11 9:48 ` rguenth at gcc dot gnu.org
2024-06-11 10:08 ` blubban at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-06-11 4:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/115423] Inlined strcmp optimizes poorly
2024-06-11 0:08 [Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly blubban at gmail dot com
2024-06-11 4:24 ` [Bug tree-optimization/115423] " pinskia at gcc dot gnu.org
@ 2024-06-11 9:48 ` rguenth at gcc dot gnu.org
2024-06-11 10:08 ` blubban at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-06-11 9:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/115423] Inlined strcmp optimizes poorly
2024-06-11 0:08 [Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly blubban at gmail dot com
2024-06-11 4:24 ` [Bug tree-optimization/115423] " pinskia at gcc dot gnu.org
2024-06-11 9:48 ` rguenth at gcc dot gnu.org
@ 2024-06-11 10:08 ` blubban at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: blubban at gmail dot com @ 2024-06-11 10:08 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-06-11 10:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-11 0:08 [Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly blubban at gmail dot com
2024-06-11 4:24 ` [Bug tree-optimization/115423] " pinskia at gcc dot gnu.org
2024-06-11 9:48 ` rguenth at gcc dot gnu.org
2024-06-11 10:08 ` blubban at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).