From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id F0F423858D39 for ; Wed, 22 Nov 2023 14:25:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0F423858D39 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 F0F423858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700663111; cv=none; b=C3XhK4w0WOuc7VWSQkSizRxRFl5NGSebQiagtGj2ihN3exaLiV6jfdSH4iKULGfUecdd4ZlVHEoBYKMJd7cgYWIsJwfw30Wyn63woVxcp8ipx6z3oHvtIvsuAwiuMSiBz0pEk28PLhIeXlt5Fn+4/dQ8Jkh+FmTA+QnAJ2CvLKk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700663111; c=relaxed/simple; bh=Bk1QiJIfoOcOrn+vQNL2Phr/wrko2EYJ35gjuS8BMw4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=QYbzGfFvssF8YNUMAnr+v8PoEm94rhPyiQCDRDRdwF31JzgDTHlYIy2PLalGm3CoKZwCIzvfqt8d5d8/3A3Xs4x6gySYseQUlVlH0O0aqgquMvLh0MzMRe44EqUKfisThNpbS9QWu5OcpJ+2OYBnzmjZqwzIZdQ3sXRjG/GsYp4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1ce5e76912aso44708905ad.2 for ; Wed, 22 Nov 2023 06:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1700663108; x=1701267908; 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=DLlLlivRf+bcfKl5WfOPWdBktTlaADqQJOef/m9NO6I=; b=ckZ+aYGLITp7PXSpe+Aq48uBg8yYJUe8nq5El4aGKhdIm/Vd3Mi6NNXdN3yhEG6zmS qwakZo7Yjz02J+M04J3B5XJ6xIfD3xuVkK8sR/rsoVQUbOy/GVjTSC8iz0WW6CvmnGpF YF2jX+enpBR8ClVuAtOxQM3+kgNLjb2WtdQojRklryOFIZV6wajZWuBJH7ksZmdbGyTi SE2r35E9v96kQZ2IhL7+HpT+7dQXYuWf9lgE0vdgtM4To1AdPDbdklNk0KLvw0YFdwR5 9QZDeSCZ588BojkCiYKxBIQK/ZiRfjweO+A/SINllPMn9uXaaMvHuFVixCg+rjzfcE/d kOfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700663108; x=1701267908; 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=DLlLlivRf+bcfKl5WfOPWdBktTlaADqQJOef/m9NO6I=; b=ba8e9Gb8L5PIwv8ITHRHQzrL3dgBBW1MpEQG1vigEPk73C1hLKXHcqjwZvDRIqcQGC SfynOEDmUUyqOob05/Yevt/s7qDU/n9yhDrKDjnV2OiLJgvPyNtWZEfG3zBvEUOsiAkV R2TjvMTA25f1ceAi8f8Uno7e+9oc6vsM60u3C2oaxmHE0xkrad01JS9yLARRPJdS95t7 IIXYvpYDCoqfD0CEyEnTy1wsA2I3QnL9f2qrlv/buThOLhOVB+KVe2rBem3xJgXP/+KG og7Z7RN6bGQl7ETfMlqAsV7H+EyDimNDTid19wBiq1QK1oAhgol5bQ2DJ4qIFX6MFAY7 V2Eg== X-Gm-Message-State: AOJu0Yyrn9hsAHC70tyZf2zBpNectLIcfQcTtW0Ar9cecubgCi2XQZVa yautLbsZJRYwzUoYX0l+5g3z/Zt/N/mwT2/fbxizbe+IVnaj7Q0XI3s8jQ== X-Google-Smtp-Source: AGHT+IHTkX4jeaAHsUuix/ACHypBeWEMCyT4/kgYVkDj9HSbDPlVlpqdqfjhDNC74K9FNKf5/dumEOy3nzbfGO+FKHo= X-Received: by 2002:a17:90b:4c0d:b0:280:1dfc:1302 with SMTP id na13-20020a17090b4c0d00b002801dfc1302mr2972404pjb.17.1700663107951; Wed, 22 Nov 2023 06:25:07 -0800 (PST) MIME-Version: 1.0 References: <202311171939484236058@rivai.ai> <799FFC52C75DBD19+2023111721411742145625@rivai.ai> <1C19D9D85FEE32C4+2023112221521872810857@rivai.ai> In-Reply-To: <1C19D9D85FEE32C4+2023112221521872810857@rivai.ai> From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Wed, 22 Nov 2023 15:24:56 +0100 Message-ID: Subject: Re: Re: RISC-V: Support XTheadVector extensions To: =?UTF-8?B?6ZKf5bGF5ZOy?= Cc: gcc-patches , "kito.cheng" , "kito.cheng" , "cooper.joshua" , "rdapp.gcc" , Jeff Law , "philipp.tomsich" , Cooper Qu , jinma , Nelson Chu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_SHORT,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 Wed, Nov 22, 2023 at 2:52=E2=80=AFPM =E9=92=9F=E5=B1=85=E5=93=B2 wrote: > > I am totally ok to approve theadvector on GCC-14 before stage 3 close > as long as it doesn't touch the current RVV codes too much and binutils s= upports theadvector. > > I have provided the draft approach: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637349.html > which turns out doesn't need to change any codes of vector.md. > I strongly suggest follow this draft. I can be actively review theadvecto= r during stage 3. > And hopefully can help you land theadvector on GCC-14. I see now two approaches: 1) Let GCC emit RVV instructions for XTheadVector for instructions that are in both 2) Use the ASM_OUTPUT_OPCODE hook to output "th." for these instructions No doubt, the ASM_OUTPUT_OPCODE hook approach is better than our format-string approach, but would 1) not be the even better solution? It would also mean, that not a single test case is required for these overlapping instructions (only a few tests that ensure that we don't emit RVV instructions that are not available in XTheadVector). Besides that, letting GCC emit RVV instructions for XTheadVector is a very clever idea, because it fully utilizes the fact that both extensions overlap to a huge degree. The ASM_OUTPUT_OPCODE approach could lead to an issue if we enable XTheadVe= ctor with any other vector extension, say Zvfoo. In this case the Zvfoo instructions will all be prefixed as well with "th.". I know that it is not likely to run into this problem (such a machine does not exist in real hardware), but it is possible to trigger this issue easily and approach 1) would not have this potential issue. Thanks, Christoph > > Thanks. > > ________________________________ > juzhe.zhong@rivai.ai > > > From: Christoph M=C3=BCllner > Date: 2023-11-22 18:07 > To: juzhe.zhong@rivai.ai > CC: gcc-patches; kito.cheng; Kito.cheng; cooper.joshua; Robin Dapp; jeffr= eyalaw; Philipp Tomsich; Cooper Qu; Jin Ma; Nelson Chu > Subject: Re: RISC-V: Support XTheadVector extensions > Hi Juzhe, > > Sorry for the late reply, but I was not on CC, so I missed this email. > > On Fri, Nov 17, 2023 at 2:41=E2=80=AFPM juzhe.zhong@rivai.ai > wrote: > > > > Ok. I just read the theadvector extension. > > > > https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadv= ector.adoc > > > > Theadvector is not custom extension. Just a uarch to disable some of th= e RVV1.0 extension > > Theadvector can be considered as subextension of 'V' extension with dis= abling some of the > > instructions and adding some new thead vector target load/store (This i= s another story). > > > > So, for disabling the instruction that theadvector doesn't support. > > You don't need to touch such many codes. > > > > Here is a much simpler approach to do (I think it's definitely working)= : > > 1. Don't change any codes in vector.md and keep GCC generates ASM with = "th." prefix. > > 2. Add !TARGET_THEADVECTOR into vector-iterator.md to disable the mode = you don't want. > > For example , theadvector doesn't support fractional vector. > > > > Then it's pretty simple: > > > > RVVMF2SI "TARGET_VECTOR && !TARGET_THEADVECTOR". > > > > 3. Remove all the tests you add in this patch. > > 4. You can add theadvector specific load/store for example, th.vlb inst= ructions they are allowed. > > 5. Modify binutils, and make th.vmulh.vv as the pseudo instruction of v= mulh.vv > > 6. So with compile option "-S", you will still see ASM as "vmulh.vv". = but with objdump, you will see th.vmulh.vv. > > Yes, all these points sound reasonable, to minimize the patchset size. > I believe in point 1 you meant "without th. prefix". > > I've added Jin Ma (who is the main author of the Binutils patchset) so > he is also aware > of the proposal to use pseudo instructions to avoid duplication in Binuti= ls. > > Thank you very much! > Christoph > > > > > > After this change, you can send V2, then I can continue to review on GC= C-15. > > > > Thanks. > > > > ________________________________ > > juzhe.zhong@rivai.ai > > > > > > From: juzhe.zhong@rivai.ai > > Date: 2023-11-17 19:39 > > To: gcc-patches > > CC: kito.cheng; kito.cheng; cooper.joshua; Robin Dapp; jeffreyalaw > > Subject: RISC-V: Support XTheadVector extensions > > 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")] V= MULH) > > (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 = 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. > > > > 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.zhong@rivai.ai >