On Fri, Nov 17, 2023 at 12:40 PM juzhe.zh...@rivai.ai <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.
Palmer already outlined the reason why this has been implemented in HW. I want to add some comments on the specification and the design of the SW support. We have to face the fact here, that T-Head implemented the 0.7.1 draft version of RVV (plus a VLENB CSR). I don't want to waste time and discuss who is to blame for that (this has been done elsewhere in enough detail). Also, there are mechanisms now in place to avoid that something like this happens again. When we call this extension "RVV-0.7.1-draft" (plus VLENB), then we are facing arguments that claim that a RVV "draft" cannot be treated as a ratified extension. Further, there are arguments that only one RVV extension exists (the one that was ratified). Therefore, T-Head's vector extension was several times described as a "custom-extension", which is "non-conforming" (uses encoding space of standard extension). Of course, this hides the fact that the extension is identical to RVV 1.0 to a high degree. Anyway, I don't think that these arguments and descriptions are wrong. So, in order to avoid pointless discussions about what it is, and why it is what it is, we simply accepted this description and gave the extension the name XTheadVector. In RISC-V vendor instructions and CSRs need to have vendor prefixes ("th."). The specification can be found (together with all other XThead* extensions) here: https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc Some further details, which are worth mentioning here about this specification: * Factional LMUL values are not supported. * Zvlsseg was an extension in RVV 0.7.1, but is part in RVV 1.0. Since T-Head has these instructions as well, we followed the RVV 1.0 idea and made these instructions mandatory for XTheadVector (ie. avoiding introduction of useless extensions). * Zvamo was an extension in RVV 0.7.1, which was dropped in RVV 1.0. Since T-Head has these instructions as well, we defined XTheadZvamo. So the result is that we have a custom extension, which uses the RVI encoding space and which "by accident" has a huge overlap with RVV 1.0. We are all fine with this, as long as this is our ticket to get the extension supported upstream (in the sense that everyone's opinions are respected and a solution is found which will not trigger useless discussions about things that happened a long time ago). The implementation follows this idea: it is a vendor extension and is kept as separate as possible from standard extensions. However, avoid duplication was one of our most important goals, so we came up with reusing the overlapping functionality by just adding the instruction prefixes. For the intrinsics API, we use a more user-friendly (pragmatic) approach: * state the set of supported RVV intrinsic functions * state the missing support of fractional LMUL values * list the extension-specific intrinsic functions for the additional load/store functionality I hope this gives a good overview of our reasoning. Let me know if you have further questions. BR Christoph > > Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long > as all other RISC-V maintainers agree. > > > ________________________________ > juzhe.zh...@rivai.ai