From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) by sourceware.org (Postfix) with ESMTPS id E5F6A3858D28 for ; Tue, 29 Nov 2022 01:38:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E5F6A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-vk1-xa33.google.com with SMTP id n191so1346185vkf.2 for ; Mon, 28 Nov 2022 17:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GGqbDLPqKvAx4+1HdnMUEU1dyY+jPJLA8/hq3QcmLjc=; b=Re1v2cn7kOj8fUISsR9oOuv4QsaYtWQB0syMQTNkpYEpupxjLB2kG/9CGQ1z2wiho/ oS7HkuysVqypd9856fykwD9e+QkBXNgFvv5KazUnHyK6YJfKsVbCjheQNkr1g7DwE26Q yyugT0vbWGr8rTG7fx0k8/YNHixXzOIVHuJXQ2VXlhpTqZLw8JRQWQqveEPXDTcl+XLl xfnlw7H1oABiDnOIWOQJsp8ZQkBS1SV+yapXTugSuCCemghJiKgxbD689ZwYXWoZExUl eYMR7ySKrWge0oyafEHA9Sg+C7pYSV5qMkdB8nNdVbcieZori3TFNr+ZBrZm6zCOv/MM 9CUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=GGqbDLPqKvAx4+1HdnMUEU1dyY+jPJLA8/hq3QcmLjc=; b=qbNnLxQKgjIaLEciuvsnn/n1eumbVRLKpYULhqDTP9jruhscnBrQXd1HFvsmWkf1Vx 368b8c384HIoB78uwbXaqLE3bLshbvVrxdC2H/6rDOpG9iSbMmO7DoDchGZrgN8qyHPf onbSf2/GVjZpzBtrVJ3UJ8UzWN46R9sXYvQTQ6v24dI/XgK9+cK3EbU8xikKfphU0m/r vn9OLJNmTzwSRuWeTwbWQdWV2k59dRM7qrzWcUapDmjaVOXic6aPJ9L2YN7058/zINbZ BgMWCcV1FWG6BXxojfCVw+OWjsJdd+HwHsxJR810l2o/3BFjccRZWb8FfQM4RwgBMVp/ xvJQ== X-Gm-Message-State: ANoB5pn1OOHj3kUknTrrFTws5LLZDeQftDNg3F5A9Bxpr2pGEockOKmI gLZDad/7AZEI5Z3UAUNo2SbPoESp/TzfL3QngFc= X-Google-Smtp-Source: AA0mqf7u9YX0tfXS/WF09kvqfo8e5REtpcNYofJoeVeiZmxt27mBgCHpcu1LhuoTP1BeMvMEYHr5ZwDB/6uj7VMrlRA= X-Received: by 2002:a1f:ac54:0:b0:3bc:cf4a:94f5 with SMTP id v81-20020a1fac54000000b003bccf4a94f5mr5956817vke.5.1669685935947; Mon, 28 Nov 2022 17:38:55 -0800 (PST) MIME-Version: 1.0 References: <20221128141406.242953-1-juzhe.zhong@rivai.ai> <7BF53C765A4D8817+202211290652169080217@rivai.ai> In-Reply-To: From: Kito Cheng Date: Tue, 29 Nov 2022 09:38:43 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS To: Jeff Law Cc: =?UTF-8?B?6ZKf5bGF5ZOy?= , gcc-patches , palmer Content-Type: multipart/alternative; boundary="0000000000001942c005ee920d39" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: --0000000000001942c005ee920d39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E6=96=BC 2022=E5=B9=B41= 1=E6=9C=8829=E6=97=A5 =E9=80=B1=E4=BA=8C 07:54 =E5=AF=AB=E9=81=93=EF=BC=9A > > > On 11/28/22 15:52, =E9=92=9F=E5=B1=85=E5=93=B2 wrote: > > >> I'm tempted to push this into the next stage1 given its arrival aft= er > >>>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 implement= ed > > 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 > --0000000000001942c005ee920d39--