From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) by sourceware.org (Postfix) with ESMTPS id 7DF933858421 for ; Sat, 18 Nov 2023 09:12:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DF933858421 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7DF933858421 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c2a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700298722; cv=none; b=SsgdUxM/CV6Suho/F8PeHFNJhoHM0+6usfoiNTtVl4Qo9wCmUhFQuDeOHodQBe3bJgfkfTeL9xCMabQUJX5geP4JvdmAeRuOZtclDVMWHgOaopnrnVn/ZP1rGN8VAFP3fgqFo0AhAbuNWqHQoWev+1MLrnzxGqGxRYf//sO7XCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700298722; c=relaxed/simple; bh=eOplmaIWVXjZFWZ8z50cT6abHo0OOJeZib0W5jl6SmM=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=V0vVJ0LS81mnYpomoZOWjKAc1Z693zD9ap7E8E5MoA/XVmB3+y/zQj2PN/3qQLiiSTaO8vhXgfLY4vmKqzAF9SLe9w0aF3T/GDvB3wf0e1ApAdKYJOgN5AlqKk5FmtjvI2yCugEdkJ52XbKlTbSMLcqyCz0GY4Fi6MTlvcePstY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-58a0d0cdcc1so1690929eaf.1 for ; Sat, 18 Nov 2023 01:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1700298719; x=1700903519; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TKR/OIkjtgrKO+P3fr6bEpnIT366DBii0/zbh9mu0Bg=; b=gu8kN0Xmg/ChElc4LV3UiSwagLrmVLKU5JZGcaQqxwuzMUqhKS9wajkY5QWed9n6N8 CLe1eSObDcwg7pmkBju+kNgpYB/3RXr4DLCMcad+cmLbklH2uQtxqBjqQFso4Q5D/glt V47wcapz7rB0xV9FDJBrRsv/URwNKoosPccALi8y7zl82HJv0+mfqmqbsYgZSJnASq9d HEYoK0DHE0mHmvHOKiqDahzOORiBBM5BNckE9YWPZqbjURSUmG8SlL/jOkwI72vU+6wn PPf3ERqSpmuzygiDwMfdzj1g+s9CMtGqWinqsNNNZj/vy4fHTN0/COoMTKX+1mbo2WGW H3jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700298719; x=1700903519; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TKR/OIkjtgrKO+P3fr6bEpnIT366DBii0/zbh9mu0Bg=; b=HqFNrqOIsgCYPwwkLQ4ugBWCHdd/ipTIsR1vz7YzWyXrccnxMDsTpkMKAsRr2kJhMC BaatI3jxotL8vEPZDxKsSEspesC6OFrg5O22U/XCuz/1MAWmGjZ6NNWrshPPjbqAzCvj 8kDiq0TW0yR/6vidg5boMF/v+5dFMiTCI13MPAUBvaJOAiF3Hgy1X1190klsFeBa3tx6 Ti5ltQksC3q1/VYJ2JnwPhGXdTWoHScJDiGwV9GIcbnR+qGJsWj/i2P66nAEu52vihlU f1a+7PRH9Xmbig0NC0nOG6nM1auXNG54IkjZodD3vC/sFy/EwcSDkU4Hb/tu1KUpRMRq h9Lg== X-Gm-Message-State: AOJu0YwdRtf6FIsMi+KwqgePT90hr/sUG0rOr/Dw+jp122wLyHMple3u PBizo00WB9H2RWvx5MklXPWzAVuc2E0BoGnDlwcBAA== X-Google-Smtp-Source: AGHT+IEugWZf73CDYK5M58F78rBvJUjGQNCCnVvzwNwkCnOtRbQZm9y49uAKfpKEezl9dNlyNYpwjsuhPJOHksZpJ6k= X-Received: by 2002:a05:6870:e38a:b0:1ef:fa20:3812 with SMTP id x10-20020a056870e38a00b001effa203812mr2582362oad.13.1700298719712; Sat, 18 Nov 2023 01:11:59 -0800 (PST) MIME-Version: 1.0 References: <086123810F5FEA3C+202311171939484236058@rivai.ai> In-Reply-To: <086123810F5FEA3C+202311171939484236058@rivai.ai> From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Sat, 18 Nov 2023 10:11:46 +0100 Message-ID: Subject: Re: RISC-V: Support XTheadVector extensions To: "juzhe.zhong@rivai.ai" Cc: gcc-patches , "kito.cheng" , "kito.cheng" , "cooper.joshua" , Robin Dapp , jeffreyalaw , Philipp Tomsich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Nov 17, 2023 at 12:40=E2=80=AFPM 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_scalar" > (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMU= LH) > (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] > "TARGET_VECTOR" > - "vmulh.vx\t%0,%3,%z4%p1" > + "%^vmulh.vx\t%0,%3,%z4%p1" > [(set_attr "type" "vimul") > (set_attr "mode" "")]) > > + if (letter =3D=3D '^') > + { > + 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 RV= V1.0. > Why do you invent the such ISA doesn't include any features that RVV1.0 d= oesn'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/xtheadvec= tor.adoc Some further details, which are worth mentioning here about this specificat= ion: * 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 l= ong as all other RISC-V maintainers agree. > > > ________________________________ > juzhe.zhong@rivai.ai