[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

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.