[Bug target/112295] New: RISC-V: Short forward branch pessimisation for ALU operations

[Bug target/112295] New: RISC-V: Short forward branch pessimisation for ALU operations

[macro at orcam dot me.uk]

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

            Bug ID: 112295
           Summary: RISC-V: Short forward branch pessimisation for ALU
                    operations
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: macro at orcam dot me.uk
  Target Milestone: ---
            Target: riscv*-*-*

We have a pessimisation in the RISC-V backend for TARGET_SFB_ALU.
This code:

int
addsifeq (double w, double x, int y, int z)
{
  return w == x ? y + z : y;
}

built with:

$ gcc -mtune=sifive-7-series -O1 addsifeq.c

compiles to this:

        feq.d   a4,fa0,fa1
        addw    a5,a0,a1
        bne     a4,zero,1f      # movcc
        mv      a5,a0
1:
        mv      a0,a5
        ret

however by avoiding the SFB optimisation, e.g. with:

$ gcc -mtune=sifive-5-series -O1 addsifeq.c

we get clearly superior code, which actually still benefits from SFB:

        feq.d   a5,fa0,fa1
        beq     a5,zero,.L2
        addw    a0,a0,a1
.L2:
        ret

This can be fixed by providing `addMcc' patterns for TARGET_SFB_ALU,
but how about other ALU operations?

Filing as a PR as I may or may not have time to work on this, so let's
have it written down.

[Bug target/112295] RISC-V: Short forward branch pessimisation for ALU operations

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-30
     Ever confirmed|0                           |1
                 CC|                            |palmer at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from palmer at gcc dot gnu.org ---
IIRC something along these lines came up when originally doing the SFB stuff. 
I don't remember if the SiFive 7-series can fuse the proposed code as there's
an extra a0 read in there.  I do remember missing some fusion opportunities but
deciding they weren't worth worrying about at the time as the CMOV got most of
the benefit.

Even if SiFive can't fuse these, we'll probably end up with implementations
that can at some point.  So IMO it's a valid missed optimization.

[Bug target/112295] RISC-V: Short forward branch pessimisation for ALU operations

[andrew at sifive dot com]

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

Andrew Waterman <andrew at sifive dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrew at sifive dot com

--- Comment #2 from Andrew Waterman <andrew at sifive dot com> ---
SiFive 7-series cores will fuse the second version, too, so it's obviously
preferable.  (I know there exist other cores that will only perform this fusion
if the branch shadow contains only a move, but they should have their own
optimization settings.)