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

["andrew at sifive dot com" <gcc-bugzilla@gcc.gnu.org>]

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.