[Bug tree-optimization/114761] New: Ignored [[likely]] attribute

[Bug tree-optimization/114761] New: Ignored [[likely]] attribute

[zamazan4ik at tut dot by]

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

[Bug tree-optimization/114761] Ignored [[likely]] attribute

[pinskia at gcc dot gnu.org]

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.

[Bug middle-end/114761] Ignored [[likely]] attribute

[pinskia at gcc dot gnu.org]

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 ...

[Bug middle-end/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing

[pinskia at gcc dot gnu.org]

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?

[Bug tree-optimization/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/114761] Ignored [[likely]] attribute with multiple if statements doing the same thing

[zamazan4ik at tut dot by]

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.