[Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants

[Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants

[gabravier at gmail dot com]

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

            Bug ID: 102402
           Summary: Seemingly suboptimal optimization of jmp/cmovcc for
                    conditionally loading constants
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include <stdint.h>

struct MusicPlayerTrack
{
    uint8_t flags;
    uint8_t modT;
};

void ClearModM(struct MusicPlayerTrack *track, uint8_t modT)
{
    if (track->modT == 0)
        track->flags |= 3;
    else
        track->flags |= 12;
}

This is optimized weirdly by GCC. Leaving it as-is gives this AMD64 assembly:

ClearModM:
  movzx edx, BYTE PTR [rdi]
  mov eax, edx
  or eax, 12
  cmp BYTE PTR [rdi+1], 0
  jne .L3
  mov eax, edx
  or eax, 3
.L3:
  mov BYTE PTR [rdi], al
  ret

Whereas changing the `if` to `if (modT == 0)` gives this:

ClearModM:
  movzx eax, BYTE PTR [rdi]
  mov edx, eax
  or eax, 12
  or edx, 3
  test sil, sil
  cmove eax, edx
  mov BYTE PTR [rdi], al
  ret

It seems to me that this should be better than the first output, though of
course this could be the other way considering how finicky cmovcc seems to be,
but it seems to me like at least one should be preferred above the other.

Note that this also occurs on IA-32, so the issue seems unrelated to whether
modT is in a register or in memory. Perhaps it's about whether it's a function
argument ?

[Bug tree-optimization/102402] Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
          Component|target                      |tree-optimization
   Last reconfirmed|                            |2021-09-18
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, note the best code is generated by:
void ClearModM1(struct MusicPlayerTrack *track, uint8_t modT)
{
    int t =0;
    if (track->modT == 0)
        t = 3;
    else
        t = 12;
    track->flags |= t;
}

This is then a gimple level issue where:
  if (_1 == 0)
    goto <bb 3>; [50.00%]
  else
    goto <bb 4>; [50.00%]

  <bb 3> [local count: 536870913]:
  _3 = pretmp_6 | 3;
  goto <bb 5>; [100.00%]

  <bb 4> [local count: 536870913]:
  _5 = pretmp_6 | 12;

  <bb 5> [local count: 1073741824]:
  # cstore_12 = PHI <_3(3), _5(4)>
is not transformed into:
    if (track->modT == 0)
        t = 3;
    else
        t = 12;
cstore_12 = pretmp_6  | t;

There is also a sinking issue though I don't know if has a wider effect (and
does not matter in this case really).
Take:
void ClearModM1(struct MusicPlayerTrack *track, uint8_t modT)
{
    int t =0;
    int t2 = track->modT;
    int t1 = track->flags;
    if (t2 == 0)
        t = 3;
    else
        t = 12;
    track->flags = t1|t;
}
The load for track->flags is not sunk after the if.