[Bug target/106585] New: RISC-V: Mis-optimized code gen for zbs

[Bug target/106585] New: RISC-V: Mis-optimized code gen for zbs

[kito at gcc dot gnu.org]

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

            Bug ID: 106585
           Summary: RISC-V: Mis-optimized code gen for zbs
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kito at gcc dot gnu.org
  Target Milestone: ---
            Target: riscv

Command:
$ riscv64-unknown-elf-gcc foo.c -o - -S -O3 -march=rv64imafdc_zbb_zbs

```c
int foo(int rs1, int rs2) {
  return (rs1 & ~(1<<rs2));
}
```

Current code gen:
```asm
foo:
        li      a5,1
        sllw    a5,a5,a1
        andn    a0,a0,a5
        sext.w  a0,a0
        ret
```

And even worth if compile without zbb
```asm
foo:
        li      a5,1
        sllw    a5,a5,a1
        andn    a0,a0,a5
        sext.w  a0,a0
        ret
```

clang code gen:
```
foo:
        bclr    a0, a0, a1
        sext.w  a0, a0
        ret
```

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Interesting rv32i_zbb produces:
foo:
        bclr    a0,a0,a1
        ret

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
One issue is RV32i_zbb produces:
(insn 8 4 9 2 (set (reg:SI 78)
        (ashift:SI (const_int 1 [0x1])
            (subreg:QI (reg/v:SI 76 [ rs2 ]) 0))) "t6.c":3:20 323 {*bsetsi_1}
     (expr_list:REG_DEAD (reg/v:SI 76 [ rs2 ])
        (nil)))


While RV64i_zbb does not match:
(insn 7 4 8 2 (set (reg:SI 79)
        (const_int 1 [0x1])) "t6.c":3:20 140 {*movsi_internal}
     (nil))
(insn 8 7 9 2 (set (reg:SI 78)
        (ashift:SI (reg:SI 79)
            (subreg:QI (reg/v:DI 76 [ rs2 ]) 0))) "t6.c":3:20 154 {ashlsi3}
     (expr_list:REG_DEAD (reg:SI 79)
        (expr_list:REG_DEAD (reg/v:DI 76 [ rs2 ])
            (expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
                    (subreg:QI (reg/v:DI 76 [ rs2 ]) 0))
                (nil)))))

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(define_insn "*bset<mode>"
  [(set (match_operand:X 0 "register_operand" "=r")
        (ior:X (ashift:X (const_int 1)
                         (match_operand:QI 2 "register_operand" "r"))
               (match_operand:X 1 "register_operand" "r")))]
  "TARGET_ZBS"
  "bset\t%0,%1,%2"
  [(set_attr "type" "bitmanip")])

It uses X iterator here instead of GPR, hmmm ...

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[kito at gcc dot gnu.org]

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

--- Comment #4 from Kito Cheng <kito at gcc dot gnu.org> ---
> It uses X iterator here instead of GPR, hmmm ...

I think that because we have w-variant before, so use X rather than GPR here,
but apparently we should revise this.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[kito at gcc dot gnu.org]

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

--- Comment #5 from Kito Cheng <kito at gcc dot gnu.org> ---
bset generated after change X to GPR for most zbs pattern:

```
foo:
        bset    a1,x0,a1
        andn    a0,a0,a1
        sext.w  a0,a0
        ret

```

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-08-11
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Kito Cheng from comment #5)
> bset generated after change X to GPR for most zbs pattern:

Most likely most of bitmanip.md patterns should be changed to GPR instead of X.
 Just someone will need to do the work there.
(changing *bclr<mode> pattern to GPR should improve this one to bclr too).

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Raphael and I are poking at this a bit.  I can't convince myself that it's
actually safe to use GPR for the bit manipulation patterns.

For rv64 I'm pretty sure the b* instructions are operating on 64bit quantities
only.  Meaning they might twiddle the SI sign bit without extending.  If we
were to change these patterns to use GPR and the result then fed an addw (for
example) then we would have inconsistent register state as operand twiddled by
the prior b* pattern wouldn't have been sign extended.

To be clear, I think this is a limitation imposed by the ISA docs, not GCC
where this will be reasonably well defined.

With that in mind I think the only path forward is new patterns that (sadly)
use explicit subregs for sources, but still set a DImode destination.

I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly, don't
hesitate to let me know.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palmer at gcc dot gnu.org

--- Comment #8 from palmer at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #7)
> Raphael and I are poking at this a bit.  I can't convince myself that it's
> actually safe to use GPR for the bit manipulation patterns.
> 
> For rv64 I'm pretty sure the b* instructions are operating on 64bit
> quantities only.  Meaning they might twiddle the SI sign bit without
> extending.  If we were to change these patterns to use GPR and the result
> then fed an addw (for example) then we would have inconsistent register
> state as operand twiddled by the prior b* pattern wouldn't have been sign
> extended.
> 
> To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> where this will be reasonably well defined.

So you're worried about addw (and the various other OP-32 instructions) needing
signed extended high parts in registers in order to function as expected?  I've
never gotten that from the ISA manual, there might be some vestigial MIPS-isms
floating around the RISC-V port that indicate that though (as we've got similar
constraints for the comparisons).

That said, I'v gone and actually read the ISA manual here and it's not at all
specific.  I'm seeing

    ADDW and SUBW are RV64I-only instructions that are defined analogously
    to ADD and SUB but operate on 32-bit values and produce signed 32-bit
    results.  Overflows are ignored, and the low 32-bits of the result is
    sign-extended to 64-bits and written to the destination register.

which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
far as I can tell "32-bit values" isn't defined anywhere, so that's not so
useful.

Do you know if there's any hardware that needs extended values for addw and
friends?  That'd almost certainly break a lot of binaries, but I could
certainly buy an argument saying it's to the spec (and the actual words in the
spec, not just this "anything goes" compatibility stuff).

> With that in mind I think the only path forward is new patterns that (sadly)
> use explicit subregs for sources, but still set a DImode destination.
> 
> I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> don't hesitate to let me know.

Kind of just a related FYI: the comparison instructions and various bits of the
ABI do require values in canonical forms (the ABI stuff isn't exactly sign
extended, but there's a rule).  That's all a big fragile.

Re: [Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[Andrew Waterman]

On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs
<gcc-bugs@gcc.gnu.org> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
>
> palmer at gcc dot gnu.org changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |palmer at gcc dot gnu.org
>
> --- Comment #8 from palmer at gcc dot gnu.org ---
> (In reply to Jeffrey A. Law from comment #7)
> > Raphael and I are poking at this a bit.  I can't convince myself that it's
> > actually safe to use GPR for the bit manipulation patterns.
> >
> > For rv64 I'm pretty sure the b* instructions are operating on 64bit
> > quantities only.  Meaning they might twiddle the SI sign bit without
> > extending.  If we were to change these patterns to use GPR and the result
> > then fed an addw (for example) then we would have inconsistent register
> > state as operand twiddled by the prior b* pattern wouldn't have been sign
> > extended.
> >
> > To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> > where this will be reasonably well defined.
>
> So you're worried about addw (and the various other OP-32 instructions) needing
> signed extended high parts in registers in order to function as expected?  I've
> never gotten that from the ISA manual, there might be some vestigial MIPS-isms
> floating around the RISC-V port that indicate that though (as we've got similar
> constraints for the comparisons).
>
> That said, I'v gone and actually read the ISA manual here and it's not at all
> specific.  I'm seeing
>
>     ADDW and SUBW are RV64I-only instructions that are defined analogously
>     to ADD and SUB but operate on 32-bit values and produce signed 32-bit
>     results.  Overflows are ignored, and the low 32-bits of the result is
>     sign-extended to 64-bits and written to the destination register.
>
> which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
> far as I can tell "32-bit values" isn't defined anywhere, so that's not so
> useful.
>
> Do you know if there's any hardware that needs extended values for addw and
> friends?  That'd almost certainly break a lot of binaries, but I could
> certainly buy an argument saying it's to the spec (and the actual words in the
> spec, not just this "anything goes" compatibility stuff).

The spec explicitly says that the upper 32 bits of the inputs are
ignored; you just need to read a few paragraphs up.
https://github.com/riscv/riscv-isa-manual/blob/b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21

>
> > With that in mind I think the only path forward is new patterns that (sadly)
> > use explicit subregs for sources, but still set a DImode destination.
> >
> > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> > don't hesitate to let me know.
>
> Kind of just a related FYI: the comparison instructions and various bits of the
> ABI do require values in canonical forms (the ABI stuff isn't exactly sign
> extended, but there's a rule).  That's all a big fragile.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[andrew at sifive dot com]

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

--- Comment #9 from Andrew Waterman <andrew at sifive dot com> ---
On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs
<gcc-bugs@gcc.gnu.org> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
>
> palmer at gcc dot gnu.org changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |palmer at gcc dot gnu.org
>
> --- Comment #8 from palmer at gcc dot gnu.org ---
> (In reply to Jeffrey A. Law from comment #7)
> > Raphael and I are poking at this a bit.  I can't convince myself that it's
> > actually safe to use GPR for the bit manipulation patterns.
> >
> > For rv64 I'm pretty sure the b* instructions are operating on 64bit
> > quantities only.  Meaning they might twiddle the SI sign bit without
> > extending.  If we were to change these patterns to use GPR and the result
> > then fed an addw (for example) then we would have inconsistent register
> > state as operand twiddled by the prior b* pattern wouldn't have been sign
> > extended.
> >
> > To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> > where this will be reasonably well defined.
>
> So you're worried about addw (and the various other OP-32 instructions) needing
> signed extended high parts in registers in order to function as expected?  I've
> never gotten that from the ISA manual, there might be some vestigial MIPS-isms
> floating around the RISC-V port that indicate that though (as we've got similar
> constraints for the comparisons).
>
> That said, I'v gone and actually read the ISA manual here and it's not at all
> specific.  I'm seeing
>
>     ADDW and SUBW are RV64I-only instructions that are defined analogously
>     to ADD and SUB but operate on 32-bit values and produce signed 32-bit
>     results.  Overflows are ignored, and the low 32-bits of the result is
>     sign-extended to 64-bits and written to the destination register.
>
> which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
> far as I can tell "32-bit values" isn't defined anywhere, so that's not so
> useful.
>
> Do you know if there's any hardware that needs extended values for addw and
> friends?  That'd almost certainly break a lot of binaries, but I could
> certainly buy an argument saying it's to the spec (and the actual words in the
> spec, not just this "anything goes" compatibility stuff).

The spec explicitly says that the upper 32 bits of the inputs are
ignored; you just need to read a few paragraphs up.
https://github.com/riscv/riscv-isa-manual/blob/b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21

>
> > With that in mind I think the only path forward is new patterns that (sadly)
> > use explicit subregs for sources, but still set a DImode destination.
> >
> > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> > don't hesitate to let me know.
>
> Kind of just a related FYI: the comparison instructions and various bits of the
> ABI do require values in canonical forms (the ABI stuff isn't exactly sign
> extended, but there's a rule).  That's all a big fragile.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[palmer at gcc dot gnu.org]

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

--- Comment #10 from palmer at gcc dot gnu.org ---
(In reply to Andrew Waterman from comment #9)
> On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs
> <gcc-bugs@gcc.gnu.org> wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
> >
> > palmer at gcc dot gnu.org changed:
> >
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >                  CC|                            |palmer at gcc dot gnu.org
> >
> > --- Comment #8 from palmer at gcc dot gnu.org ---
> > (In reply to Jeffrey A. Law from comment #7)
> > > Raphael and I are poking at this a bit.  I can't convince myself that it's
> > > actually safe to use GPR for the bit manipulation patterns.
> > >
> > > For rv64 I'm pretty sure the b* instructions are operating on 64bit
> > > quantities only.  Meaning they might twiddle the SI sign bit without
> > > extending.  If we were to change these patterns to use GPR and the result
> > > then fed an addw (for example) then we would have inconsistent register
> > > state as operand twiddled by the prior b* pattern wouldn't have been sign
> > > extended.
> > >
> > > To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> > > where this will be reasonably well defined.
> >
> > So you're worried about addw (and the various other OP-32 instructions) needing
> > signed extended high parts in registers in order to function as expected?  I've
> > never gotten that from the ISA manual, there might be some vestigial MIPS-isms
> > floating around the RISC-V port that indicate that though (as we've got similar
> > constraints for the comparisons).
> >
> > That said, I'v gone and actually read the ISA manual here and it's not at all
> > specific.  I'm seeing
> >
> >     ADDW and SUBW are RV64I-only instructions that are defined analogously
> >     to ADD and SUB but operate on 32-bit values and produce signed 32-bit
> >     results.  Overflows are ignored, and the low 32-bits of the result is
> >     sign-extended to 64-bits and written to the destination register.
> >
> > which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
> > far as I can tell "32-bit values" isn't defined anywhere, so that's not so
> > useful.
> >
> > Do you know if there's any hardware that needs extended values for addw and
> > friends?  That'd almost certainly break a lot of binaries, but I could
> > certainly buy an argument saying it's to the spec (and the actual words in the
> > spec, not just this "anything goes" compatibility stuff).
> 
> The spec explicitly says that the upper 32 bits of the inputs are
> ignored; you just need to read a few paragraphs up.
> https://github.com/riscv/riscv-isa-manual/blob/
> b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21

Ah, sorry I missed that.  So I think we're fine from the ISA side of things,
it's just the SW constraints to worry about.

> 
> >
> > > With that in mind I think the only path forward is new patterns that (sadly)
> > > use explicit subregs for sources, but still set a DImode destination.
> > >
> > > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> > > don't hesitate to let me know.
> >
> > Kind of just a related FYI: the comparison instructions and various bits of the
> > ABI do require values in canonical forms (the ABI stuff isn't exactly sign
> > extended, but there's a rule).  That's all a big fragile.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Coming back to this.

WRT extension elimination.  I've been pondering if we want a late pass to do a
bit of this that can't be handled by REE.

So let's take the case of a Zbs instruction operating on a variable bit in
RV64.

I think we can probably agree that in the absence of additional information we
can't do those kind of bit manipulations because we could potentially change
bit 31 and have the result escape as a parameter to a function call, return
value or get used in a compare type instruction.


So to make use of the Zbs instructions that manipulate a variable bit we could
could emit a suitable sign extension after each such operation.  That, of
course, has the potential to be expensive.

But if we chase down the uses we can probably eliminate a lot of these
extensions.  Essentially we need to know if the extension reaches a comparison,
one of the ABI escape points or a real 64bit operation.  If not, then the
extension is unnecessary and can be dropped.

Ideally we'd find that a significant number of extensions could be dropped.

We're not actively working on this, but it is something rattling around in the
empty space between my ears.