From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id C58373858C83 for ; Mon, 28 Nov 2022 23:14:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C58373858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x435.google.com with SMTP id a9so8563410pfr.0 for ; Mon, 28 Nov 2022 15:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; 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=LmN2zVdx3QrMH9Tzor5C73svVGtkA1OgE1gHRmYU7Qk=; b=hgB2LjwwWYW3TD8x91jdqt6sl/Wr9SQDWe0T4IMmxrUxMTAJcYQHkHtMRS/3zrHE+8 eckuXvlx2Wc1m5fWtgt20GCr9sUxi8mPDXQlyVpevByA7jXrCnUPb6WrjH4mYmsxerWH 84hxTtT30g+S4Yb8ZwiYjsXcLTQKVugM1FD2bZUssDhj5mzVptsXF1vY6rVrSGsXzWkf UDsMPSi/zcmzvGPGZ7OWsoUjhZt2I1kK8rckVOITH68z20jVrz2tVDTHMeqfczg/UlbK CWcswRBXAdnCpFMj5p/4Rnag2CZNxTGmAnpBD3XGsISkw1R7MtMGLIegGpROE2f56XPj 1duA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=LmN2zVdx3QrMH9Tzor5C73svVGtkA1OgE1gHRmYU7Qk=; b=PzYFb7obYohZxqlliHzEG88Kc6a8ufj2asqZ1ItLfMEN0jnjDQ2mHYFsmkxR/KjBl7 12AcAxQSi1qKrDHXq+tsiBAnzHRA5nhBsgqG2ta9JpoxCmUiXklUFcVJS89485ZxO965 NYgSRCbpuYVl0FGMTwGtC5yIpAGKhZuhstXqNYNN62HgZvSP40L17eZvjNqmnlZNH3Dp y4mVmqjb3pZO5niv0nTmiTUe7I1Qj9R+wC2ABmilaujvd4Kl2xQeWbPz5o5KRPIChP/v 5YboJ4zNp/hQLDnYsR0UoWwm0Fs3g8VW4dG/z9zlhepo/MScxWRjd1t5rhckdmvbilb1 C3WA== X-Gm-Message-State: ANoB5pmSUAKaWPUT20hosoNCuTdEMJBptfXoA6pzivbdtq2GTewKU0ov 0l/zpY889I8wh4mHte3mfxpfUg== X-Google-Smtp-Source: AA0mqf7OWiWg/IVB7SET+7pYgMkkbDntEczikXoX44Uw7Mo8UXHTnngP/+s7BGCTEVBymwM4ZRXlXg== X-Received: by 2002:a05:6a00:26c8:b0:574:c159:ce3b with SMTP id p8-20020a056a0026c800b00574c159ce3bmr18184375pfw.74.1669677266480; Mon, 28 Nov 2022 15:14:26 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id w11-20020a170902ca0b00b001868ed86a95sm9276217pld.174.2022.11.28.15.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 15:14:26 -0800 (PST) Date: Mon, 28 Nov 2022 15:14:26 -0800 (PST) X-Google-Original-Date: Mon, 28 Nov 2022 15:14:17 PST (-0800) Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS In-Reply-To: CC: jeffreyalaw@gmail.com, gcc-patches@gcc.gnu.org, Kito Cheng From: Palmer Dabbelt To: juzhe.zhong@rivai.ai 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=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zhong@rivai.ai wrote: > Thanks. > > I think we still can continue RVV feature reviewing process in github branch > that we have talked about. Such patches that have been reviewed I will still send > them to GCC mail list and not to merge right now, we can wait until stage1 is open. That also works for me. We can always stack them up on a vendor branch for a few months until things re-open. > Is it a good idea ? I don't want to make RVV support in GCC stop here since LLVM already has > all RVV support and GCC is far behind LLVM for a long time in case of RVV. Yes, please don't stop ;). It's really important work! > > > juzhe.zhong@rivai.ai > > From: Palmer Dabbelt > Date: 2022-11-29 02:02 > To: jeffreyalaw > CC: juzhe.zhong; gcc-patches; Kito Cheng > Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS > On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreyalaw@gmail.com wrote: >> >> On 11/28/22 07:14, juzhe.zhong@rivai.ai wrote: >>> From: Ju-Zhe Zhong >>> >>> gcc/ChangeLog: >>> >>> * config/riscv/riscv-protos.h (enum vlmul_type): New enum. >>> (get_vlmul): New function. >>> (get_ratio): Ditto. >>> * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct. >>> (ENTRY): Adapt for attributes. >>> (enum vlmul_type): New enum. >>> (get_vlmul): New function. >>> (get_ratio): New function. >>> * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for attributes. >>> * config/riscv/riscv.cc (ENTRY): Ditto. >>> * config/riscv/vector.md (false,true): Add attributes. >> >> I'm tempted to push this into the next stage1 given its arrival after >> stage1 close, but if the wider RISC-V maintainers want to see it move >> forward, I don't object strongly. > > I'm also on the fence here: the RISC-V V implementation is a huge > feature so it's a bit awkward to land it this late in the release, but > on the flip side it's a very important feature. It's complicated enough > that whatever our first release is will probably be a mess, so I'd > prefer to just get that pain out of the way sooner rather than later. > There's no V hardware availiable now and nothing concretely announced so > any users are probably going to be pretty advanced, but having at least > the basics of V in there will allow us to kick the tires on the rest of > the stack a lot more easily. > > There's obviously risk to taking something this late in the process. We > don't have anything else that triggers the vectorizer, so I think it > should be seperable enough that risk is manageable. > > Not sure if Kito wants to chim in, though. > >> I'm curious about the model you're using. Is it going to be something >> similar to mode switching? That's the first mental model that comes to >> mind. Essentially we determine the VL needed for every chunk of code, >> then we do an LCM like algorithm to find the optimal placement points >> for VL sets to minimize the number of VL sets across all the paths >> through the CFG. Never in a million years would I have expected we'd be >> considering reusing that code. >> >> >> Jeff >