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

["palmer at gcc dot gnu.org" <gcc-bugzilla@gcc.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.