public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/114761] New: Ignored [[likely]] attribute
@ 2024-04-18 5:04 zamazan4ik at tut dot by
2024-04-18 5:09 ` [Bug tree-optimization/114761] " pinskia at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: zamazan4ik at tut dot by @ 2024-04-18 5:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Bug ID: 114761
Summary: Ignored [[likely]] attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zamazan4ik at tut dot by
Target Milestone: ---
For the following code:
bool foo(int var)
{
if (var == 42) [[unlikely]] return true;
if (var == 322) [[unlikely]] return true;
if (var == 1337) [[likely]] return true;
return false;
}
GCC (trunk) with "-O3 -std=c++20" generates the following:
foo(int):
cmp edi, 322
sete al
cmp edi, 42
sete dl
or eax, edx
cmp edi, 1337
sete dl
or eax, edx
ret
Clang (18) with "-O3 -std=c++20" however, generates a bit different version:
foo(int): # @foo(int)
mov al, 1
cmp edi, 1337
jne .LBB0_1
.LBB0_4:
ret
.LBB0_1:
cmp edi, 42
je .LBB0_4
cmp edi, 322
je .LBB0_4
xor eax, eax
ret
GCC for some reason ignores [[likely]] attribute and doesn't place the branch
with 1337 at the beginning of the function. Clang does it. Placing this branch
at the beginning should be more optimal. I also tested GCC 13.2 (on my Fedora
machine) with __builtin_expect and PGO - the result is the same for GCC: it
ignores such an optimization.
Godbolt link: https://godbolt.org/z/o8KMx8M33
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug tree-optimization/114761] Ignored [[likely]] attribute
2024-04-18 5:04 [Bug tree-optimization/114761] New: Ignored [[likely]] attribute zamazan4ik at tut dot by
@ 2024-04-18 5:09 ` pinskia at gcc dot gnu.org
2024-04-18 5:44 ` [Bug middle-end/114761] " pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-18 5:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=107642
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem is we combine them early into an or and then expand then into if
statements but the order has changed.
For aarch64, gcc will always produce ccmp here. Which I suspect is better than
a jump.
For x86, the expansion comes during expand due to branch cost (macro inside
gcc). See pr 107642 for some more on part of this subject.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114761] Ignored [[likely]] attribute
2024-04-18 5:04 [Bug tree-optimization/114761] New: Ignored [[likely]] attribute zamazan4ik at tut dot by
2024-04-18 5:09 ` [Bug tree-optimization/114761] " pinskia at gcc dot gnu.org
@ 2024-04-18 5:44 ` pinskia at gcc dot gnu.org
2024-04-18 5:45 ` [Bug middle-end/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing pinskia at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-18 5:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|tree-optimization |middle-end
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am not so sure which one is better really.
So what I think clang is doing is this, turn if the statements into a switch
and then expanding the switch into a bunch of if statements and have the
highest probability one first. This is a decent way to "rotate" the if
statements. But I don't think it will help this case though because GCC still
likes to combine them into one without a branch (which might be better
overall).
I noticed that clang does not do any combining and producing ccmp for aarch64
(even if you remove all of the [[unlikely]]/[[likely]]). So it produces worse
code there. a branch for the combined unlikely case might be worse.
Also gcc tends to ignore the probilitity when it comes to combining because
combining almost improves code ...
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing
2024-04-18 5:04 [Bug tree-optimization/114761] New: Ignored [[likely]] attribute zamazan4ik at tut dot by
2024-04-18 5:09 ` [Bug tree-optimization/114761] " pinskia at gcc dot gnu.org
2024-04-18 5:44 ` [Bug middle-end/114761] " pinskia at gcc dot gnu.org
@ 2024-04-18 5:45 ` pinskia at gcc dot gnu.org
2024-04-18 6:55 ` [Bug tree-optimization/114761] " rguenth at gcc dot gnu.org
2024-04-18 11:30 ` zamazan4ik at tut dot by
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-18 5:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is this based on real code or you just was looking at the differences between
gcc and clang here?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug tree-optimization/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing
2024-04-18 5:04 [Bug tree-optimization/114761] New: Ignored [[likely]] attribute zamazan4ik at tut dot by
` (2 preceding siblings ...)
2024-04-18 5:45 ` [Bug middle-end/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing pinskia at gcc dot gnu.org
@ 2024-04-18 6:55 ` rguenth at gcc dot gnu.org
2024-04-18 11:30 ` zamazan4ik at tut dot by
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-04-18 6:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-04-18
Ever confirmed|0 |1
Component|middle-end |tree-optimization
CC| |mjires at gcc dot gnu.org
Version|unknown |14.0
Status|UNCONFIRMED |NEW
Keywords| |missed-optimization
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think if-to-switch might be confused by the PREDICT_EXPRs? It has
;; Canonical GIMPLE case clusters: 42 322 1337
but does nothing here. It might also not preserve profile.
I agree that attacking this through if-to-switch and switch expansion is
the way to go.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug tree-optimization/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing
2024-04-18 5:04 [Bug tree-optimization/114761] New: Ignored [[likely]] attribute zamazan4ik at tut dot by
` (3 preceding siblings ...)
2024-04-18 6:55 ` [Bug tree-optimization/114761] " rguenth at gcc dot gnu.org
@ 2024-04-18 11:30 ` zamazan4ik at tut dot by
4 siblings, 0 replies; 6+ messages in thread
From: zamazan4ik at tut dot by @ 2024-04-18 11:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
--- Comment #5 from Alexander Zaitsev <zamazan4ik at tut dot by> ---
> Is this based on real code or you just was looking at the differences between gcc and clang here?
Really, not on a real code. I came up with this example when I found that GCC
for this example doesn't reorganize branches according to PGO profiles (when
Clang does it). I just wondered about this difference in behavior between
compilers, and trying to figure out what compiler is "right" here.
Regarding generated code efficiency between Clang and GCC in this case. Am I
right that in this case ignoring branch probabilities (in the GCC case) doesn't
affect actual code performance? Asking it since I am not so proficient in
compiler optimizations.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-18 11:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-18 5:04 [Bug tree-optimization/114761] New: Ignored [[likely]] attribute zamazan4ik at tut dot by
2024-04-18 5:09 ` [Bug tree-optimization/114761] " pinskia at gcc dot gnu.org
2024-04-18 5:44 ` [Bug middle-end/114761] " pinskia at gcc dot gnu.org
2024-04-18 5:45 ` [Bug middle-end/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing pinskia at gcc dot gnu.org
2024-04-18 6:55 ` [Bug tree-optimization/114761] " rguenth at gcc dot gnu.org
2024-04-18 11:30 ` zamazan4ik at tut dot by
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).