From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id F27853858D20 for ; Tue, 30 May 2023 09:32:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F27853858D20 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-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2af2b74d258so44698261fa.3 for ; Tue, 30 May 2023 02:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685439122; x=1688031122; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kL4ihvSF6l4eGTWPJqTzJTqLFpWeqWj862ZnO9gnISk=; b=U4N+MipQ7UaQaMLxYxqKvU59UVqnPeP9rhluXiY2yg96BLk2TIbcJsAAqzqDC+kpmF 6Mnkd6/pbbNdMm9rJSwVpI4GZHF9TIGCnoxlYMHr21kM9tOrMIOkL60ZedIqrcQq297g 8xA0KRW/JYBYJeejNgWlM6fpISrmqunqPxN198z9pWA2ovuErGHJWNuOE15bJWsfwpvB mEhkgD8zzSMCg7mV7Rrnc+t0Q2b81BP6Ud7Q6xT6jUH2Tx+gqxdnfS2it2axp/vSdJlA b/AZUHtQgz/4pycGS8/V+7rP/nZ9z5vKWtJvTBMcHzF6z7RPyPZeVUJu5j/IHp04bHa+ 9sgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685439122; x=1688031122; h=content-transfer-encoding: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=kL4ihvSF6l4eGTWPJqTzJTqLFpWeqWj862ZnO9gnISk=; b=kXZ3Zh40pr6+BDOICtWGTRAdYxPQ/YltgIJ6KdQ35btPhWXuvPUbAP4MGPt0ioFdfC pzWSgAYkcMg7QTXcc+CVmi7O3YXDlWNs0ruyju7CzcyPzSl1x3D655O2BUZsgYVQ3S10 IStx5920Fmo8NJdwbDlK8lO8hTJeKGPo2Z9XRqr1LDiviu3bYWdaLu2ZuLZx2gJ/OwHs YQ8rC2GLZb7bfaZNe07HLsUPscMJW+wT5oBU+zLUhQMJd4HX7aQ68WTeabdNyOYJMxmn jcfOeeIiM/e9Jyh7pxGRmsZvKlmUwvXqfwcXdL59ORCUZQ71oCQoGfh36sZibLo0CdbU v7ag== X-Gm-Message-State: AC+VfDzTYLTdc54th5ppS63pgN0HUXSGa8L2mlNWtQ9tth6jFVGxFwJP eSl8kIZjDnbQKp3JwNmmQ5o++3rlo8UViEel7Jo= X-Google-Smtp-Source: ACHHUZ6h7oOaC1veQaDFZT2Y0Y9t7+zRdNwhi0Ps0fVtsHKgy7wKQM9rU2/jQymk8ZFJ384nw30sgr6AUnFUkEBqak4= X-Received: by 2002:a2e:3e01:0:b0:2b0:4953:e535 with SMTP id l1-20020a2e3e01000000b002b04953e535mr505252lja.19.1685439121996; Tue, 30 May 2023 02:32:01 -0700 (PDT) MIME-Version: 1.0 References: <20230530060621.31449-1-kito.cheng@sifive.com> <87B2E2DEA59DF7D1+20230530154530505119343@rivai.ai> <5873dbb5-ef8f-6411-1841-d849030554e3@gmail.com> In-Reply-To: From: Richard Biener Date: Tue, 30 May 2023 11:29:47 +0200 Message-ID: Subject: Re: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V To: "juzhe.zhong@rivai.ai" Cc: Robin Dapp , "Kito.cheng" , gcc-patches , palmer , "kito.cheng" , jeffreyalaw , "pan2.li" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Tue, May 30, 2023 at 11:17=E2=80=AFAM juzhe.zhong@rivai.ai wrote: > > In the future, we will definitely mixing VLA and VLS-vlmin together in a = codegen and it will not cause any issues. > For VLS-vlmin, I prefer it is used in length style auto-vectorization (I = am not sure since my SELECT_VL patch is not > finished, I will check if can work when I am working in SELECT_VL patch). For the future it would be then good to have the vectorizer re-vectorize loops with VLS vector uses to VLA style? I think there's a PR with a draft patch from a few years ago attached (from me) somewhere. Currently the vectorizer will give up when seeing vector operations in a loop but ideally those should simply be SLPed. > >> In general I don't have a good overview of which optimizations we gain= by > >> such an approach or rather which ones are prevented by VLA altogether? > These patches VLS modes can help for SLP auto-vectorization. > > ________________________________ > juzhe.zhong@rivai.ai > > > From: Robin Dapp > Date: 2023-05-30 17:05 > To: juzhe.zhong@rivai.ai; Richard Biener; Kito.cheng > CC: rdapp.gcc; gcc-patches; palmer; kito.cheng; jeffreyalaw; pan2.li > Subject: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V > >>> but ideally the user would be able to specify -mrvv-size=3D32 for an > >>> implementation with 32 byte vectors and then vector lowering would ma= ke use > >>> of vectors up to 32 bytes? > > > > Actually, we don't want to specify -mrvv-size =3D 32 to enable vectoriz= ation on GNU vectors. > > You can take a look this example: > > https://godbolt.org/z/3jYqoM84h > > > > GCC need to specify the mrvv size to enable GNU vectors and the codegen= only can run on CPU with vector-length =3D 128bit. > > However, LLVM doesn't need to specify the vector length, and the codege= n can run on any CPU with RVV vector-length >=3D 128 bits. > > > > This is what this patch want to do. > > > > Thanks. > I think Richard's question was rather if it wasn't better to do it more > generically and lower vectors to what either the current cpu or what the > user specified rather than just 16-byte vectors (i.e. indeed a fixed > vlmin and not a fixed vlmin =3D=3D fixed vlmax). > > This patch assumes everything is fixed for optimization purposes and then > switches over to variable-length when nothing can be changed anymore. Th= at > is, we would work on "vlmin"-sized chunks in a VLA fashion at runtime? > We would need to make sure that no pass after reload makes use of VLA > properties at all. > > In general I don't have a good overview of which optimizations we gain by > such an approach or rather which ones are prevented by VLA altogether? > What's the idea for the future? Still use LEN_LOAD et al. (and masking) > with "fixed vlmin"? Wouldn't we select different IVs with this patch tha= n > what we would have for pure VLA? > > Regards > Robin >