Re: RISC-V: Support XTheadVector extensions

[Palmer Dabbelt <palmer@dabbelt.com>]

On Fri, 17 Nov 2023 03:39:48 PST (-0800), juzhe.zhong@rivai.ai wrote:
> 90% theadvector extension reusing current RVV 1.0 instructions patterns:
> Just change ASM, For example:
> 
> @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar"
>  	     (match_operand:VFULLI_D 3 "register_operand"  "vr,vr, vr, vr")] VMULH)
>  	  (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu,  0")))]
>    "TARGET_VECTOR"
> -  "vmulh<v_su>.vx\t%0,%3,%z4%p1"
> +  "%^vmulh<v_su>.vx\t%0,%3,%z4%p1"
>    [(set_attr "type" "vimul")
>     (set_attr "mode" "<MODE>")])
> +  if (letter == '^')
> +    {
> +      if (TARGET_XTHEADVECTOR)
> +	fputs ("th.", file);
> +      return;
> +    }
> 
> For almost all patterns, you just simply append "th." in the ASM prefix.
> like change "vmulh.vv" -> "th.vmulh.vv"
> 
> Almost all theadvector instructions are not new features,  all same as RVV1.0.
> Why do you invent the such ISA doesn't include any features that RVV1.0 doesn't satisfy ?
> 
> I am not explicitly object this patch. But I should know the reason.

There's some more in the later threads, but with the top posting it kind 
of got lost so I'm just replying here.

This really isn't T-Head's fault: we announced V-0.7 as a stable draft 
that was being implemented, and then T-Head went and implemented it.  
Most of that history has been scrubbed by RVI, but you can still find 
some stuff like this old talk on YouTube 
<https://www.youtube.com/watch?v=F66F1nT1T8o>.

In general we've just figured out a way to make things work when HW 
vendors end up in a grey area in RISC-V land.  That obviously results in 
a bunch of pain for the SW people, but this stuff is only useful if we 
can run on real HW and that always involves some amount of pain.  
Hopefully we can get to a point where we make fewer problems for 
ourselves, but we've got a long history to dig out from and there's 
going to be a lot more of this in the future.

So I don't like this XTHeadV stuff, but I think we're best to take it: 
these guys tried to do the right thing and got thrown under the bus by 
RVI, we should help them.  This is almost certainly going to be a lot 
more pain that we're used to, just given the size of the extensions in 
question, but I still think it's the right  way to go.

The other option is to essentially just tell them to fork the ISA, which 
isn't good for anyone.

> Btw, stage 1 will close soon.  So I will review this patch on GCC-15 as long as all other RISC-V maintainers agree.

I agree this is gcc-15 material: there's a lot of subtle differences in 
behavior between 0.7 and 1.0, even when the mnemonics are the same.  
We're already pretty buried in testing for 14, so trying to pick up 
another target is going to be a huge headache (particularly one that's a 
bit special).

> 
> 
> 
> 
> juzhe.zhong@rivai.ai