From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 326883858C54 for ; Tue, 28 Nov 2023 19:45:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 326883858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 326883858C54 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::532 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701200707; cv=none; b=h71ci/s691rmveF01lr3jAE6+Fyd//0+1Pkh8cAS2gfTvNhUr9aTVW/moj59emgDIiwYTRl2y02TIMjt1c9arCn2Bkc+Ju30MJeEgQG21hz3+EGz4mZ4dn1nd6+qn5Oe6Mf9cEjgDmi07EEM7PTh/KhsBkNhIEEKprJv89O4afU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701200707; c=relaxed/simple; bh=yMRWQ5kJCQBKrVMdjBKUqPZFVKIudX176UHiDaZ6Rwo=; h=DKIM-Signature:Date:Subject:From:To:Message-ID:Mime-Version; b=YOmSX7Y9yCgzAd2gnFlqa8SnILr/EwWWbUzNfBI4+0pgi/sDfdZWWSvcs76pT2ZeZO5EPo6bA34m/6tMCJxgUPf+SNlf3jyjaBWCHBIe9R8Krr2ebu56eD3rqXlT0MKMKoliUP+FvSPsdj6n+WY1GBeznpSWpKIYuC8jwLdfpSA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5c1acc1fa98so114443a12.0 for ; Tue, 28 Nov 2023 11:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1701200705; x=1701805505; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=fl1x/Tvw14B+p9mjG6rLhBMJp1hLYPCruUbkiqF/gdo=; b=cqy2gJJv7vlWTZjvQHTq52dpLxFU2eNCbyQ/iVzwyTV8iSrfonsOqmfesEcXFyhb8H yPxbvtTwo5XWhs/DhBBBwHbi1uJe/R00VNHvvBhSLXYSo30fl6sdUFRD9VaUqkK01yZG mBRPubFyhGZqnnw08TwebjaHvPL+Bwq+IwptfzTbsDKjR+rjTOhvHq2RTDHRkXY2Yo69 JHTTFJZyFM3C0DsD4zh7OrOKIQF9kHnlckNaiPdhI3fG+5zDG9f4qPHbV0wK6xaw4vYQ R6w/tJTSZrQcaFg2zOkS3Nd0sIDCVax/klviAQeOaEmTHG+ZCY91PTHpZkmvXrIMJnml 0Rqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701200705; x=1701805505; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fl1x/Tvw14B+p9mjG6rLhBMJp1hLYPCruUbkiqF/gdo=; b=uqYghNcyEkpz0qz6SNSELqCPt/vaISgfGCYzuJzLtvoXB+1g2VMYypCwjeo5L+63BE YyurbH6GwC/+j+qasJwEo4ivLOkpHzabb6SjbNGHil1VZBQWKBAB1KTnpfhK25XtI0Kc Nv5bsptwVS0on6SJOCbHwp5A4is17k0A2KFZ6O7A0K/tQoamgG0kxm1RQfISPdmUElMg DfFOtMm4aHy/nUUHR2jvfosBockpA9d3FtVYvxFXDS5RTyfKI23nEvHwlqquIpozoeo8 XVGmDb5DK3xrcpiPues6R95GIE981pZtKtsLTM9dNJ8KzyOAbgVu8ismKXfy2fw/LoG9 8d4g== X-Gm-Message-State: AOJu0YwBMIO6EVd5lvJXCZrZBmVLzGQ5HdElHWcqdS+2fySGJzlnkKlM YXfCXJmCvS6fORWO3iybbYUBhw== X-Google-Smtp-Source: AGHT+IEUAvd3qoJXTAkXRHFRbijCCrO4+a0VzrjbFNcvC1s0ADLvpqzWA0hm1F95YEEbsOraZ48zmg== X-Received: by 2002:a17:90b:380c:b0:285:b08a:7817 with SMTP id mq12-20020a17090b380c00b00285b08a7817mr15143452pjb.13.1701200704961; Tue, 28 Nov 2023 11:45:04 -0800 (PST) Received: from localhost ([12.44.203.122]) by smtp.gmail.com with ESMTPSA id bv17-20020a17090af19100b0028017a2a8fasm9427278pjb.3.2023.11.28.11.45.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 11:45:04 -0800 (PST) Date: Tue, 28 Nov 2023 11:45:04 -0800 (PST) X-Google-Original-Date: Tue, 28 Nov 2023 11:45:00 PST (-0800) Subject: Re: RISC-V: Support XTheadVector extensions In-Reply-To: <67df2e14-448a-4b2f-970e-63bff13cb17f@gmail.com> CC: juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org, Kito Cheng , kito.cheng@sifive.com, cooper.joshua@linux.alibaba.com, Robin Dapp From: Palmer Dabbelt To: jeffreyalaw@gmail.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreyalaw@gmail.com wrote: > > > On 11/17/23 16:16, 钟居哲 wrote: >> >> 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. > I suspect it's going to be even worse if you we have multiple patterns > with the same underlying RTL, but just different output strings. > > The standard way to handle that has been with an output modifier and/or > ASSEMBLER_DIALECT. If you look at the PA port for example, the > assembler syntax changed dramatically between the PA1.0/PA1.1 era and > the PA2.0 era. But we support both variants trivially without > duplicating all the patterns. IMO we're just stuck between a rock and a hard place here. Specifically, this isn't just an assembly syntax change but also comes with a bunch of behaviorial changes to the instructions in question -- I'm specifically thinking of things like the register packing, which IIRC changed a ton between 0.7 and 0.8 (and then again more for 1.0). That's the kind of stuff that tends to have non-local implications on the port, and thus can trip people up. So if we model this as just assembly syntax then we risk people tripping over the differences, but if we try to model it as a whole different extension then we have more code to manage. I'd start with the assembly syntax approach, as it should be the option with less code which is always nice. If that turns out to be a problem then we can always just duplicate the patterns, but it's way harder to merge them back together if we start out with things duplicated. During the patchwork call we also ended up talking about the P extension (and the likely vendor flavors). Nothing's appeared for there yet, but the theory is that the RZ/Five (Renesas' line of RISC-V chips that came out earlier this year) has some P-related extension. There's also some SIMD in CORE-V, as well as a bunch of low-hanging fruit missing from V that we'll probably see more vendor extensions for. So I think if the goal is to have a single vector target for RISC-V then we've probably lost already. > But we've got time to sort this out. I don't think the code in question > was targeted towards gcc-14. [In case anyone else is watching: see the forked thread, it might be amied for 14 now...] > > > jeff