From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 7B7213857C51 for ; Tue, 29 Nov 2022 03:11:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B7213857C51 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-x42f.google.com with SMTP id w129so12420023pfb.5 for ; Mon, 28 Nov 2022 19:11:51 -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=e0RJrKZppg8VG72LdXTUs9Fo7Cz7hc3m5nPOHAaBXZc=; b=qUE9tAlgZzxJv3Kk0noPJRA9t981IcfYBK3DH5rDjOTprvSclTmNNO8PKeHgMKEbwv saqWvkavlt4r8ot0GiTlwrI+CW6hV9Z7UcFzXEafvME8Q9H/yc78uRdfwgUMyVz3Rfu9 blV66QSb5HT7KyFzeTBhauQxDOs98uocIo7kspMvVSepYGZIrwSDoWLZSAYvBpb16IC6 f++OIl+ltkANtf2y6SQTYnw44+ASdlSeI5oLSDqIs5jJASy14RyKeLlCUuhs1GEgCuMJ zrx8irkaLHfsgDEkD3Rc/ysAuvCzIgWpu6uxnSmPZI7VmFt2ATRmR0gurOLdyT3fwAsc 9kJA== 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=e0RJrKZppg8VG72LdXTUs9Fo7Cz7hc3m5nPOHAaBXZc=; b=c+BT64RmzX+ujZZo1FMXB/bd7RezXDbb/Yxh24JIo1XhD0wszpUMPMRploJid2Qq6X ANVwZyBGySdSD5ZKy8aRnN+qQBPImKyrO5iBwK6gd1X3TplNUPSD9IPoQnJDEwfPAUzJ S9Oezdnemncr7LQagW/XkCp2Eia6+sXI4GN4NJzg39pTOXLGsgYPDeaG4w9siHZK8zeY 5/rupS55Xrap5Q4KjRqOuPdXZjEUllmLirxftwydzgBInlyT7W15s36/TWa+joU9H1pl O15YzOx2IojM82ifHeRpBsN5wtanPuO7yjDMhvkuzClEZGRvfYJK5d9/cMsqqV21T5MX N1nA== X-Gm-Message-State: ANoB5pkwqxuiYressfrw7JHZ5YeahnxXfTsnZJ1YXvJNogbvKfFcqTt6 H7D3Zp2lJYGeo0Qdqo11Ae8dag== X-Google-Smtp-Source: AA0mqf6M0uVrgltD8hPC0bIvLobjZqA9sL4j3o4Gd4o1NjzlkX3wTiHJNWhrCbOY4ADzGyP4+OdaqQ== X-Received: by 2002:a63:db0a:0:b0:459:35b1:1396 with SMTP id e10-20020a63db0a000000b0045935b11396mr32989306pgg.593.1669691510271; Mon, 28 Nov 2022 19:11:50 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id k34-20020a63ff22000000b0047048c201e3sm7393956pgi.33.2022.11.28.19.11.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 19:11:49 -0800 (PST) Date: Mon, 28 Nov 2022 19:11:49 -0800 (PST) X-Google-Original-Date: Mon, 28 Nov 2022 19:11:40 PST (-0800) Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS In-Reply-To: <857D9AB0A9FDBE2B+2022112911072427600551@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 19:07:24 PST (-0800), juzhe.zhong@rivai.ai wrote: > In case of RVV intrinsic support, there is no changes outside RISC-V backend > since we don't do the autovectorization support for now. OK, I'm fine with that. Sounds like Kito is too? > I will postpone autovectorization until GCC14 is open. We can still review that stuff and keep it on a branch, if that's eaiser on your end. > > > juzhe.zhong@rivai.ai > > From: Palmer Dabbelt > Date: 2022-11-29 10:56 > To: juzhe.zhong > CC: Kito Cheng; jeffreyalaw; gcc-patches > Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS > 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 >