From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id C956E3858C3A for ; Tue, 29 Nov 2022 02:56:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C956E3858C3A 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-pg1-x534.google.com with SMTP id f9so11742327pgf.7 for ; Mon, 28 Nov 2022 18:56:04 -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=w69HP2b2X9VtYMaYC3Imz6Zjegn330oRXFhjzR5fuLo=; b=v5XU6HN6zDRLzDTHsEZteFiAsGTPG2rG71/nP1aRK0h4er2aiUmV4xfA1cTEjkK8/y T5OxHlGhxBkMz77MO0QNAPkxggh3HO0/hdTbjYHcafaiwSglaFGSUTVEAqgsAvLm1xhI 39NFdDCNo0dUmrxP6UH90oR5sO6EUkjUSzL7P/ynQNRhes5oLnMezujraDoIR+cc62Ud IT1cqOUQJA2orfHIXbW+quBmWLQIZkKf8CeFCQeaArC7u6VQupAaFID0SIHT46xfBLVg uY5r05i+TLZbE+qqfc8gBxaoyTCmhS8Hw5Yb0pAbnhReMXRAegPblEnjznFA9fNwtffh gPpw== 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=w69HP2b2X9VtYMaYC3Imz6Zjegn330oRXFhjzR5fuLo=; b=3J5epaNbZQn7nX82TA7D7Kpa1bY3L+oyFFPsi+Ulxy7afYxw2iQDBRW0D7N631eD6I /lRXhagp1QwMBXtRkBMZ6eMJPx5/E+FU0LK7AY8Srla8/EqDT52Ya5jbBkUx4JZmAGns SF01EuVLbXQR6JFuML999PNk5zvJxBM6smXYI2ZSLQBEqeqCW9pFUIhAcFIiLUzD+9nC PmtQkWSa7bVBU/vSi0dJBBLxvxTW9r6Oz+6VGM30/YiXbTEqr+/VLpuNj+OZtHukqX6G 2iaOlbvwjDhO8tgUoERWzGG61K48oTXM0FNY1YISQXzhB6ZiS/8uExD7c3NC6q7JGtb5 epmw== X-Gm-Message-State: ANoB5pm2LS3hIm02+egf/XTGdItG4LvAYvdCUwTlG8cV4O1DdlLVRlPF zS6uvAN7kOYFQKt8v0EUatkyEQ== X-Google-Smtp-Source: AA0mqf5GwLsXD0J6qjlQUP9tT8JihuxJ3skhrknN1zSbpBXhueLFcNquyZq5lEefTmuGti6YmYtdmw== X-Received: by 2002:a63:5308:0:b0:46f:cec6:8805 with SMTP id h8-20020a635308000000b0046fcec68805mr31896331pgb.612.1669690563602; Mon, 28 Nov 2022 18:56:03 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id r8-20020aa79628000000b00573eb4a9a66sm8762909pfg.2.2022.11.28.18.56.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 18:56:03 -0800 (PST) Date: Mon, 28 Nov 2022 18:56:03 -0800 (PST) X-Google-Original-Date: Mon, 28 Nov 2022 18:55:53 PST (-0800) Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS In-Reply-To: <3C923BC540D474E7+2022112909461575270228@rivai.ai> CC: Kito Cheng , jeffreyalaw@gmail.com, gcc-patches@gcc.gnu.org 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=-3.5 required=5.0 tests=BAYES_00,BODY_8BITS,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 17:46:16 PST (-0800), juzhe.zhong@rivai.ai wrote: > Yeah, I personally want to support RVV intrinsics in GCC13. > As RVV intrinsic is going to release soon next week. OK, that's fine with me -- I was leaning that way, and I think Jeff only had a weak opposition. Are there any more changes required outside the RISC-V backend? Those would be the most controversial and are already late, but if it's only backend stuff at this point then I'm OK taking the risk for a bit longer. Jeff? > > > > juzhe.zhong@rivai.ai > > From: Kito Cheng > Date: 2022-11-29 09:38 > To: Jeff Law > CC: 钟居哲; gcc-patches; palmer > Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS > Actually, I am strongly support those stuff keep merge to trunk until February, my goal is intrinsic support for vector, but not including any vectorization like SLP or Loop vectorization, the most critical part is the vsetvli which is the mode switching, and its almost done. > > Those part is kind of infrastructure for future development (vectorization), so I want intrinsic support could merge at GCC 13. > > > and we've included few intrinsic support now, stop there is kind of awkward. > > Jeff Law via Gcc-patches 於 2022年11月29日 週二 07:54 寫道： > > > On 11/28/22 15:52, 钟居哲 wrote: >> >> 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. >> >> Ok, let's save these patches and merge them when GCC14 stage1 is open. >> Would you mind telling me when will stage 1 be open? > Typically it's April. As was noted elsewhere, feel free to keep > submitting patches in this space and you can certainly create a branch > where y'all can put patches to make it easier to collaborate and > ultimately merge with the trunk once stage1 is open again. > >> >> >> 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. >> >> Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework. > Yea, layering on top of RTL-SSA is probably better than the existing > mode-switching which is LCM without SSA. > >> Actually, me && kito have spent a month on VSETVL PASS and we have >> made a progress. We have tested it with a lot of testcases, turns out >> our implementation >> of VSETVL PASS in GCC has much better codegen than the VSETVL implemented >> in LLVM side in many different situations because of LCM. I am working >> on cleaning up the codes >> and hopefully you will see it soon in the next patch. > Good to hear. I argued pretty loudly in the late 90s that LCM was the > right framework for this problem. We didn't have rtl-ssa, but we did > have a pure RTL LCM module that Joern and Andrew were able to re-use to > implement sh's mode switching. > > I just never thought we'd see another processor where it'd be useful. > > Jeff