[Bug rtl-optimization/64713] New: Missed ccmp optimization

[Bug rtl-optimization/64713] New: Missed ccmp optimization

[rth at gcc dot gnu.org]

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

            Bug ID: 64713
           Summary: Missed ccmp optimization
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rth at gcc dot gnu.org

In a small percentage of ccmp uses within the stage3 cc1plus I see

  56b638:       f100045f        cmp     x2, #0x1
  56b63c:       fa421320        ccmp    x25, x2, #0x0, ne
  56b640:       1a9f17e3        cset    w3, eq
  56b644:       350001c3        cbnz    w3, ...

This is a reminder to dig those out as test cases and see if we can
eliminate the cset.

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have this too even before the recent patch.

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a testcase which shows one of the issues with removing the optimization
inside expand:
int foo_c (int a, int b)
{
  if (a > 9 && b < 34)
    return 4;
  else
    return 26;
}

if the code was:
int foo_c (int a, int b, int c, int d)
{
  if (a > 9 && b < 34)
    return c;
  else
    return d;
}

--- CUT ---
We would optimize out the cset.

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is failing this check:
  /* Make sure that the value that is to be substituted for the register
     does not use any registers whose values alter in between.  However,
     If the insns are adjacent, a use can't cross a set even though we
     think it might (this can happen for a sequence of insns each setting
     the same destination; last_set of that register might point to
     a NOTE).  If INSN has a REG_EQUIV note, the register is always
     equivalent to the memory so the substitution is valid even if there
     are intervening stores.  Also, don't move a volatile asm or
     UNSPEC_VOLATILE across any other insns.  */
  || (!all_adjacent
      && (((!MEM_P (src) || !find_reg_note (insn, REG_EQUIV, src))
       && use_crosses_set_p (src, DF_INSN_LUID (insn)))
          || (GET_CODE (src) == ASM_OPERANDS && MEM_VOLATILE_P (src))
          || GET_CODE (src) == UNSPEC_VOLATILE))

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|aarch64-linux               |aarch64*-*-linux*
         Depends on|                            |64993

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Here is a testcase which shows one of the issues with removing the
> optimization inside expand:

I don't know if this was the only issue so I filed bug 64993 for that one.

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think most of them are recorded in a different bug report. PR 100942 is where
most is recorded too.

E.g.
  82a544:       7100343f        cmp     w1, #0xd
  82a548:       7a411824        ccmp    w1, #0x1, #0x4, ne  // ne = any
  82a54c:       1a9f17f5        cset    w21, eq  // eq = none
  82a550:       540000e1        b.ne    82a56c
<_ZL9is_subseqP10conversionS0_+0x80>  // b.any