From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 5EB3138768BC for ; Wed, 22 Nov 2023 22:48:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5EB3138768BC Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5EB3138768BC Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700693316; cv=none; b=s4XlStgnnc717x6jFkAHTwE+zHqxLmqABQhrvZETeiLsN6AbxW+ZVJBiQjVky42Gmyz1fwiqPQXlsTQlKxjN81TpBrhOQhS2g453xlqdqbvoBKbgqF9mmUQiNgqQOzpsEAhohnqp6rZbNR2gpz7xdzQpb10T/2PmCdGQnpyTC9s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700693316; c=relaxed/simple; bh=aUEp/pYr2TmC6An1KVbbAmcvsRJSHk4IEoFR7j5VgKA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=vkvWsynya6bkIYXBUTMHNHx1jBawY88pbM15f0PlSEIUI4VH6Uj4IByqBXQrpvayEp91n0VDl+HTzSi88kjnG7O/HbZCrAzioDivWi+vyAxVE3d0IHzE51rC1IAZrJx8ymYvOwYt8filbFivkTGIuOsx6Lf7vT4RMFqNadyPuzc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2c6b30aca06so3696091fa.3 for ; Wed, 22 Nov 2023 14:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1700693305; x=1701298105; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ec152Sy4l+JBQm0jm4vJwNFpmbfT74vffqURUuwVQ9I=; b=StGn3EwYckVQ7yJU9tkxDMEDqsm+DjSABPXWD9ZULcg5efqb0l1Qw08adi0cqYSD7l v/tQ4p/XJpPnZq6/V8JY3xVS3CgefXzthQ1+jqzJiKYoOcuobYzvD2bbVAhxBsGnUzyQ ij0cZdPMBVHV6EkgBTgCsJTYVBOhwG/NyiDu5PAWYKxSHyclV3k8WDNCn05eedpMiz3D aT6COhqrftf6hAdMmaslQsP9zuBjsZXcZdXfREz2QA0bdVW6d2FFO6Sz7R32Onb8FQvq +dt+eDct1t/GFBPK/20iYFyWp7Iv0HNVcvaB2zCMoDOkMF5zHaMyYYVU/n4M6f/+fx0q 57uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700693305; x=1701298105; h=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=Ec152Sy4l+JBQm0jm4vJwNFpmbfT74vffqURUuwVQ9I=; b=Gcm+AhBxysNn8Bg05lZDds+XZxstVD/Bwj9TLdRXPyWYuSpTLxoWra42MNqBHzKnNn woXnX8xFF+zVdrt43+CXwAdPUZFwKjyTv0sJK8cFe7HWY5SjE/BChy6QMDSjMRVPIfJE mVNY361zM09u5UyTJtEs3VTQTF8x9Ic/oetWEbLECYxIFvUM23giyRX3f/6MGs4K3/HT 4yB0OBclMi91v76bSpY4D0FUF1OzH9CLYpEH//9dUjjbKS9B5F5z2yX8ONCpVmngpXtp +xeG729D39eCt/BJU6QjwFLvfn+c+aldfypYVgzCeZcmUG8mcSpBnVZ38px6i2Ys07Xn PCvQ== X-Gm-Message-State: AOJu0Ywx31J/XLxrkwlBGIm1v0Xffd067Rox/4ZHcNFpckFyCUSynlg5 P1yHrwai1FGxPITZ742oviMM9sh1XZyzDdj6y3HIdg== X-Google-Smtp-Source: AGHT+IGNwq06ckig3nDOGYGx6R3jUSXOlLzZoHREj8XSxy3RZYs12ymjW92jsIa8+2bAgcMgbL8pXLDHsLGpC0unvJo= X-Received: by 2002:a2e:8751:0:b0:2c5:2d16:6d93 with SMTP id q17-20020a2e8751000000b002c52d166d93mr2528650ljj.28.1700693305016; Wed, 22 Nov 2023 14:48:25 -0800 (PST) MIME-Version: 1.0 References: <202311171939484236058@rivai.ai> <799FFC52C75DBD19+2023111721411742145625@rivai.ai> <1C19D9D85FEE32C4+2023112221521872810857@rivai.ai> <81fc1cc3-2fa2-4cac-a0b1-5272a2a09535@gmail.com> In-Reply-To: <81fc1cc3-2fa2-4cac-a0b1-5272a2a09535@gmail.com> From: Kito Cheng Date: Thu, 23 Nov 2023 06:48:12 +0800 Message-ID: Subject: Re: RISC-V: Support XTheadVector extensions To: Jeff Law Cc: =?UTF-8?Q?Christoph_M=C3=BCllner?= , =?UTF-8?B?6ZKf5bGF5ZOy?= , gcc-patches , "kito.cheng" , "cooper.joshua" , "rdapp.gcc" , "philipp.tomsich" , Cooper Qu , jinma , Nelson Chu Content-Type: multipart/alternative; boundary="000000000000516513060ac584bb" 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,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000516513060ac584bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am less worry about the thead vector combined with other zv extension, instead we should reject those combinations at all. My reason is thead vector is transitional products, they won't have any further new products with that longer, also it's not compatible with all other zv extension in theory, zv extension requires at least zve32x which is subset of v1p0, and I don't think it's valid to use thead vector as replacement required extension - it should just introduce another thead vector extension instead. Jeff Law =E6=96=BC 2023=E5=B9=B411=E6=9C=8823=E6=97= =A5 =E9=80=B1=E5=9B=9B 06:27 =E5=AF=AB=E9=81=93=EF=BC=9A > > > On 11/22/23 07:24, Christoph M=C3=BCllner wrote: > > 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 > supports 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 > theadvector 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 > XTheadVector > > 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. > I'm not a big fan of the ASM_OUTPUT_OPCODE approach. While it is > simple, I worry a bit about it from a long term maintenance standpoint. > As you note we could well end up at some point with an extension that > has an mnenomic starting with "v" that would blow up. But I certainly > see the appeal of such a simple test to support thead vector. > > Given there are at least 3 approaches that can fix that problem (%^, > assembler dialect or ASM_OUTPUT_OPCODE), maybe we could set that > discussion aside in the immediate term and see if there are other issues > that are potentially more substantial. > > > > > -- > > > > More generally, I think I need to soften my prior statement about > deferring this to gcc-15. This code was submitted in time for the > gcc-14 deadline, so it should be evaluated just like we do anything else > that makes the deadline. There are various criteria we use to evaluate > if something should get integrated and we should just work through this > series like we always do and not treat it specially in any way. > > > jeff > --000000000000516513060ac584bb--