>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
>> may also need to add '^' to the punct_valid_p hook. But yes, this is
>> the preferred way to go when all we need to do is prefix the instruction
>> with "th.".
No. I don't think we need to add '^' . I don't want theadvector to touch any
codes
of vector.md.
Mixing up theadvector with RVV1.0 is a nighmare for RVV maintain.
People like me don't want to touch any thing related to Thead.
But anyway, I will take care of that in GCC-15.
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-11-18 01:11
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; cooper.joshua; rdapp.gcc; jeffreyalaw
Subject: Re: RISC-V: Support XTheadVector extensions
On Fri, 17 Nov 2023 03:39:48 PST (-0800), juzhe.zh...@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.zh...@rivai.ai
