[Bug rtl-optimization/94798] New: Failure to optimize subtraction and 0 literal properly

[Bug rtl-optimization/94798] New: Failure to optimize subtraction and 0 literal properly

[gabravier at gmail dot com]

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

            Bug ID: 94798
           Summary: Failure to optimize subtraction and 0 literal properly
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int a, int b)
{
    return (b >= a) ? (b - a) : 0;
}

Generates some *really* bad code with GCC right now, it seems to forget such
basic things as how to set a register to 0 on x86. LLVM generates good code.

Comparison here : https://godbolt.org/z/LZ8dBy

Also, this seems to have regressed back in GCC 4.9, GCC 4.8 at least generates
a `xor reg, reg` instead of a `mov reg, 0`

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Gabriel Ravier from comment #0)
> Comparison here : https://godbolt.org/z/LZ8dBy

In your future bug reports, could you please copy all relevant information
instead of (or in addition to) linking to some external website just to show 3
lines of asm? Thanks.

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier <gabravier at gmail dot com> ---
Ok, will do that in the future. Considering I was just linking to godbolt every
time for the assembly code, should I go back to all the other bug reports that
I've made to upload assembly code there too ?

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The xor -> mov 0 change happened in
r0-126146-g3b6d16993b9d6812f6212bce4f35547fd9e40457, it isn't about gcc not
knowing how to zero registers on x86, but about the ax = 0 insn being in
between the condition code setting insn and insn that uses that, where
obviously xor can't be used.
Later, when the insn scheduler reorders those, there is no pass that would have
LR problem computed and would try specifically for these.
E.g. peephole2 has APIs to check for that easily, but sched2 is after that, so
for peephole2 all we could try is to swap the CC setter insn with the reg = 0
insn without flags clobber.
That is just speaking about the xor.

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As for the subtraction followed by comparison, I think this is something
normally optimized through peephole2, but that one doesn't trigger in this case
due to RA decisions, where it sees different operands:
(insn 33 4 26 2 (set (reg:SI 0 ax [86])
        (reg/v:SI 4 si [orig:84 b ] [84])) "pr94798.c":4:29 67
{*movsi_internal}
     (nil))
(insn 26 33 27 2 (parallel [
            (set (reg:SI 0 ax [86])
                (minus:SI (reg:SI 0 ax [86])
                    (reg/v:SI 5 di [orig:83 a ] [83])))
            (clobber (reg:CC 17 flags))
        ]) "pr94798.c":4:29 254 {*subsi_1}
     (expr_list:REG_UNUSED (reg:CC 17 flags)
        (nil)))
(insn 27 26 31 2 (set (reg:CCGC 17 flags)
        (compare:CCGC (reg/v:SI 4 si [orig:84 b ] [84])
            (reg/v:SI 5 di [orig:83 a ] [83]))) "pr94798.c":4:29 11 {*cmpsi_1}
     (expr_list:REG_DEAD (reg/v:SI 5 di [orig:83 a ] [83])
        (expr_list:REG_DEAD (reg/v:SI 4 si [orig:84 b ] [84])
            (nil))))

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Related to what I wrote in PR94802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802#c5

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |3507

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> As for the subtraction followed by comparison, I think this is something
> normally optimized through peephole2, but that one doesn't trigger in this
> case due to RA decisions, where it sees different operands:

This is basically PR 3507.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
[Bug 3507] appalling optimisation with sub/cmp on multiple targets

[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-09-04