[Bug target/113095] New: RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[Bug target/113095] New: RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[craig.topper at gmail dot com]

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

            Bug ID: 113095
           Summary: RISC-V: movcc no longer used for coremark crc
                    functions with -mtune=sifive-7-series
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: craig.topper at gmail dot com
  Target Milestone: ---

In gcc 12, the crc functions in coremark used the "movcc" macrofusion pattern
of a branch over a single mv. In gcc 13, a longer branchless sequence is used.

https://godbolt.org/z/9xvcxo5Y9

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What is the cost of the movcc here? IIRC this is really dependent on the cost
model in the backend?

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[craig.topper at gmail dot com]

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

--- Comment #2 from Craig Topper <craig.topper at gmail dot com> ---
The branch+mv macrofusion should execute together. The visible latency to other
instructions is 1 cycle.

The hardware can predicate most ALU instructions, not just mv. So even better
would be putting the xor after the branch instead of a mv.

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[craig.topper at gmail dot com]

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

--- Comment #3 from Craig Topper <craig.topper at gmail dot com> ---
Our FPGA data is showing this as a 5% regression. I'll try to check on an
Unmatched board to confirm.

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Anyways this was introduced by r13-4459-g6508d5e5a1a8c0

[Bug target/113095] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:fb54b9772816968032518d4008be5090e0d95109

commit r14-8396-gfb54b9772816968032518d4008be5090e0d95109
Author: Monk Chiang <monk.chiang@sifive.com>
Date:   Wed Jan 24 10:19:28 2024 -0700

    [PATCH v3] RISC-V: Add split pattern to generate SFB instructions.
[PR113095]

    Since the match.pd transforms (zero_one == 0) ? y : z <op> y,
    into ((typeof(y))zero_one * z) <op> y. Add splitters to recongize
    this expression to generate SFB instructions.

    gcc/ChangeLog:
            PR target/113095
            * config/riscv/sfb.md: New splitters to rewrite single bit
            sign extension as the condition to SFB instructions.

    gcc/testsuite/ChangeLog:
            * gcc.target/riscv/sfb.c: New test.
            * gcc.target/riscv/pr113095.c: New test.

[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.3
      Known to work|                            |14.0
            Summary|RISC-V: movcc no longer     |[13 Regression] RISC-V:
                   |used for coremark crc       |movcc no longer used for
                   |functions with              |coremark crc functions with
                   |-mtune=sifive-7-series      |-mtune=sifive-7-series
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-30
             Status|UNCONFIRMED                 |NEW

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Kito Cheng <kito@gcc.gnu.org>:

https://gcc.gnu.org/g:6335baaf31c0f1f0952d1a3f507b0e5655b1136f

commit r13-8663-g6335baaf31c0f1f0952d1a3f507b0e5655b1136f
Author: Monk Chiang <monk.chiang@sifive.com>
Date:   Wed Jan 24 10:19:28 2024 -0700

    [PATCH v3] RISC-V: Add split pattern to generate SFB instructions.
[PR113095]

    Since the match.pd transforms (zero_one == 0) ? y : z <op> y,
    into ((typeof(y))zero_one * z) <op> y. Add splitters to recongize
    this expression to generate SFB instructions.

    gcc/ChangeLog:
            PR target/113095
            * config/riscv/riscv.md: New splitters to rewrite single bit
            sign extension as the condition to SFB instructions.

    gcc/testsuite/ChangeLog:
            * gcc.target/riscv/sfb.c: New test.
            * gcc.target/riscv/pr113095.c: New test.

    (cherry picked from commit fb54b9772816968032518d4008be5090e0d95109)

[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

[kito at gcc dot gnu.org]

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

Kito Cheng <kito at gcc dot gnu.org> changed:

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

--- Comment #8 from Kito Cheng <kito at gcc dot gnu.org> ---
Fixed on both trunk and GCC 13