RISC-V: Fix overlapping vd/vs2 allocation for vector crypto [PR126196]

  The RISC-V Vector Crypto specification reserves encodings in which
"the vd register group overlaps with the vs2 register group" for
vsm3me.vv and vsm3c.vi, and in which "the vd register group overlaps
with either vs1 or vs2" for vsha2ms.vv, vsha2ch.vv and vsha2cl.vv.
So mark the destination of the affected define_insn patterns as
early-clobber.

	PR target/126196

gcc/ChangeLog:

	* config/riscv/vector-crypto.md (vv_ins1_con): New int attribute.
	(vi_ins1_con): Likewise.
	(@pred_v<vv_ins1_name><mode>): Mark the destination of
	vsha2ms/vsha2ch/vsha2cl as early-clobber.
	(@pred_vi<vi_ins1_name><mode>_nomaskedoff_scalar): Likewise for
	vsm3c.
	(@pred_vsm3me<mode>): Mark the destination as early-clobber.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/pr126196-1.c: New test.
	* gcc.target/riscv/pr126196-2.c: New test.
	* gcc.target/riscv/pr126196-3.c: New test.
---
 gcc/config/riscv/vector-crypto.md           | 15 ++++++++---
 gcc/testsuite/gcc.target/riscv/pr126196-1.c | 29 +++++++++++++++++++++
 gcc/testsuite/gcc.target/riscv/pr126196-2.c | 21 +++++++++++++++
 gcc/testsuite/gcc.target/riscv/pr126196-3.c | 26 ++++++++++++++++++
 4 files changed, 88 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr126196-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr126196-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr126196-3.c
  

On 9/2/26 4:48 AM, Jin Ma wrote:
> The RISC-V Vector Crypto specification reserves encodings in which
> "the vd register group overlaps with the vs2 register group" for
> vsm3me.vv and vsm3c.vi, and in which "the vd register group overlaps
> with either vs1 or vs2" for vsha2ms.vv, vsha2ch.vv and vsha2cl.vv.
> So mark the destination of the affected define_insn patterns as
> early-clobber.
>
> 	PR target/126196
>
> gcc/ChangeLog:
>
> 	* config/riscv/vector-crypto.md (vv_ins1_con): New int attribute.
> 	(vi_ins1_con): Likewise.
> 	(@pred_v<vv_ins1_name><mode>): Mark the destination of
> 	vsha2ms/vsha2ch/vsha2cl as early-clobber.
> 	(@pred_vi<vi_ins1_name><mode>_nomaskedoff_scalar): Likewise for
> 	vsm3c.
> 	(@pred_vsm3me<mode>): Mark the destination as early-clobber.
>
> gcc/testsuite/ChangeLog:
>
> 	* gcc.target/riscv/pr126196-1.c: New test.
> 	* gcc.target/riscv/pr126196-2.c: New test.
> 	* gcc.target/riscv/pr126196-3.c: New test.
Don't we have the same problem with vaes*.vs and vsm4r.vs?

Presumably there's no value in trying to use the work from Robin & Pan 
which allows for better modeling of when we can and can not have 
overlapping register/register groups in things like widening vector 
patterns?

Jeff
  

> On 9/2/26 4:48 AM, Jin Ma wrote:
> > The RISC-V Vector Crypto specification reserves encodings in which
> > "the vd register group overlaps with the vs2 register group" for
> > vsm3me.vv and vsm3c.vi, and in which "the vd register group overlaps
> > with either vs1 or vs2" for vsha2ms.vv, vsha2ch.vv and vsha2cl.vv.
> > So mark the destination of the affected define_insn patterns as
> > early-clobber.
> >
> >  PR target/126196
> >
> > gcc/ChangeLog:
> >
> >  * config/riscv/vector-crypto.md (vv_ins1_con): New int attribute.
> >  (vi_ins1_con): Likewise.
> >  (@pred_v<vv_ins1_name><mode>): Mark the destination of
> >  vsha2ms/vsha2ch/vsha2cl as early-clobber.
> >  (@pred_vi<vi_ins1_name><mode>_nomaskedoff_scalar): Likewise for
> >  vsm3c.
> >  (@pred_vsm3me<mode>): Mark the destination as early-clobber.
> >
> > gcc/testsuite/ChangeLog:
> >
> >  * gcc.target/riscv/pr126196-1.c: New test.
> >  * gcc.target/riscv/pr126196-2.c: New test.
> >  * gcc.target/riscv/pr126196-3.c: New test.
> Don't we have the same problem with vaes*.vs and vsm4r.vs?

Yes.  I went back and double-checked, and the same problem does
exist.  The "Vector/Scalar constraints" subsection (under
Instruction Constraints) of the specification explicitly lists:

  For implementations with VLEN >= 128, vs2 refers to a single
  register.  Thus, the vd register group must not overlap the vs2
  register.

  | Instruction   | Register  | Cannot Overlap |
  |---------------|-----------|----------------|
  | vaes*.vs      | vs2       | vd             |
  | vsm4r.vs      | vs2       | vd             |
  | vsha2c*       | vs1, vs2  | vd             |
  | vsha2ms       | vs1, vs2  | vd             |
  | vsm3me        | vs2       | vd             |
  | vsm3c         | vs2       | vd             |

So the vd/vs2 overlap of vaes*.vs (including vaesz.vs) and vsm4r.vs is
also a reserved encoding, and the "Reserved Encodings" paragraph of
each instruction states this individually, e.g. for vsm4r:

  * Only for the insn:*.vs[] form: the vd register group overlaps
    the vs2 register

I verified all six same-LMUL .vs intrinsic forms on trunk; each of
them generates a reserved encoding, e.g.:

  vuint32m1_t f (vuint32m1_t a, size_t vl)
  { return __riscv_vaesef_vs_u32m1_u32m1 (a, a, vl); }

compiles to "vaesef.vs v8,v8" (likewise for vaesem/vaesdf/vaesdm/
vaesz/vsm4r).

This is a pre-existing and separate issue -- this patch does not
touch those patterns.  I'll send a follow-up patch to fix it.

> Presumably there's no value in trying to use the work from Robin & Pan 
> which allows for better modeling of when we can and can not have 
> overlapping register/register groups in things like widening vector 
> patterns?

Right, there is no value here.  Robin & Pan's work (the dependent
filter constraint, e.g. Wtt / riscv_widen_overlap_ok, and the vw*
series relaxing early-clobber) goes in the opposite direction: it
removes conservative early-clobbers where the specification allows
overlap, in order to reduce register pressure, which is a performance
concern.  What we need here is to forbid overlap entirely, which is a
correctness concern, and a plain & is exactly the right tool.  The
only spot where finer modeling could theoretically pay off is
vd/vs1 overlap for vsm3me.vv (the specification only forbids overlap
with vs2, so & is conservative there); that could be relaxed with a
dependent filter in the future if performance warrants it, but it is
outside the scope of this fix.  Also, the root cause of the vaes*.vs
issue is pattern shadowing rather than register-allocation modeling,
so that machinery would not help here either.

That said, I'm not sure my understanding is correct -- any comments?

Thanks,
Jin Ma
  

On 9/2/26 9:40 AM, Jin Ma wrote:
>>
> Yes.  I went back and double-checked, and the same problem does
> exist.  The "Vector/Scalar constraints" subsection (under
> Instruction Constraints) of the specification explicitly lists:
>
>    For implementations with VLEN >= 128, vs2 refers to a single
>    register.  Thus, the vd register group must not overlap the vs2
>    register.
>
>    | Instruction   | Register  | Cannot Overlap |
>    |---------------|-----------|----------------|
>    | vaes*.vs      | vs2       | vd             |
>    | vsm4r.vs      | vs2       | vd             |
>    | vsha2c*       | vs1, vs2  | vd             |
>    | vsha2ms       | vs1, vs2  | vd             |
>    | vsm3me        | vs2       | vd             |
>    | vsm3c         | vs2       | vd             |
>
> So the vd/vs2 overlap of vaes*.vs (including vaesz.vs) and vsm4r.vs is
> also a reserved encoding, and the "Reserved Encodings" paragraph of
> each instruction states this individually, e.g. for vsm4r:
>
>    * Only for the insn:*.vs[] form: the vd register group overlaps
>      the vs2 register
>
> I verified all six same-LMUL .vs intrinsic forms on trunk; each of
> them generates a reserved encoding, e.g.:
>
>    vuint32m1_t f (vuint32m1_t a, size_t vl)
>    { return __riscv_vaesef_vs_u32m1_u32m1 (a, a, vl); }
>
> compiles to "vaesef.vs v8,v8" (likewise for vaesem/vaesdf/vaesdm/
> vaesz/vsm4r).
>
> This is a pre-existing and separate issue -- this patch does not
> touch those patterns.  I'll send a follow-up patch to fix it.
Sounds good.

>
>> Presumably there's no value in trying to use the work from Robin & Pan
>> which allows for better modeling of when we can and can not have
>> overlapping register/register groups in things like widening vector
>> patterns?
> Right, there is no value here.  Robin & Pan's work (the dependent
> filter constraint, e.g. Wtt / riscv_widen_overlap_ok, and the vw*
> series relaxing early-clobber) goes in the opposite direction: it
> removes conservative early-clobbers where the specification allows
> overlap, in order to reduce register pressure, which is a performance
> concern.  What we need here is to forbid overlap entirely, which is a
> correctness concern, and a plain & is exactly the right tool.  The
> only spot where finer modeling could theoretically pay off is
> vd/vs1 overlap for vsm3me.vv (the specification only forbids overlap
> with vs2, so & is conservative there); that could be relaxed with a
> dependent filter in the future if performance warrants it, but it is
> outside the scope of this fix.  Also, the root cause of the vaes*.vs
> issue is pattern shadowing rather than register-allocation modeling,
> so that machinery would not help here either.
>
> That said, I'm not sure my understanding is correct -- any comments?
Understood.

So for the vaes* and vsm4r, if you're using the same basic approach as 
you did for the other vector-crypto, then consider the V2 as 
pre-approved for the trunk.

Thanks,
Jeff