From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 3223E3858D20 for ; Tue, 30 May 2023 09:05:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3223E3858D20 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-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5149429c944so4935765a12.0 for ; Tue, 30 May 2023 02:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685437532; x=1688029532; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=VYx7Fk5GSH8q3QoHIhVmXpzmOygJi9bRmFusnb8tZx8=; b=YK/2hDY4kg8ljPR8qhbQYCvAqSk2FxksVjRw0BwEP1n5NLD7deS549RS8r4pa7AMAZ QjjtpyjybWAhPMGm3bxqn+V+IEsk5bi5/C4LCI98ZMb+fCo7xaXFtuli901t9ijacMy3 XXPTpP/F5J3Lo/0ij5vyoAMvfMxvxSlNmu7yr/4sYJdMJ0Z3uWdMFa8CWZ+6E9n6XdXR B2qAbO6vFE0/KItPd+h2+lBePLobKFfU7f0tYo1G8o243iXdU5pAlCs3ecZeeEWGXER/ Xxkuko8guNmay1B6fU+Ap7zII8iwBh1N88hkJVdjTlUhFvrwAqrdEsmhqsdRq7PLtcFC m9aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685437532; x=1688029532; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VYx7Fk5GSH8q3QoHIhVmXpzmOygJi9bRmFusnb8tZx8=; b=UgKTc/eazHl7rUW2RSFZ6ZNOJt5EWwEgKqPHcxk5J9Dti7Nc+/JWaoyRdqB18hDIGg Cik7TgKXDOLWvh59op2wtUETdOm+RSFJ+7nDt4MPBMLLqWcG4cISvstzG3a+0KeAbu+d lCZ1niFzliNCVjJarmNJNCm0oD5mHkkXdwPigSNRXy5fPZayVK0zKA54pghNTQOpabxO gYImxLajk7Iv14iEbLbZsbMD6mDhBJIsTY+2kHFCLk+/yvr+s4NPlWlbaEv2X6dJEwzI 0incjnkRl9uWMn30F8BrrVI3HiudfxMPjJhbnb19AQohJKm9ssVPuOau4W8gMMmmCrcG lebw== X-Gm-Message-State: AC+VfDyrs0QJ6DsIdE0ibD6f3y07aCt7pOvhqyxcs26BtNsiCAorfg1k Mu2682mXYM+Qa2c/SbexMpE= X-Google-Smtp-Source: ACHHUZ4HJ73ZrebEu5tVO3zuHmHxRtDI1bDlpDerByaYRTI/GyeQAeoUChqnApOjD9gkoeVgqqn2Hg== X-Received: by 2002:a17:907:868e:b0:973:a30d:b264 with SMTP id qa14-20020a170907868e00b00973a30db264mr1674926ejc.46.1685437531603; Tue, 30 May 2023 02:05:31 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id k3-20020a17090627c300b0096a1ba4e0d1sm7041756ejc.32.2023.05.30.02.05.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 May 2023 02:05:31 -0700 (PDT) Message-ID: <5873dbb5-ef8f-6411-1841-d849030554e3@gmail.com> Date: Tue, 30 May 2023 11:05:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: rdapp.gcc@gmail.com, gcc-patches , palmer , "kito.cheng" , jeffreyalaw , "pan2.li" Subject: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V Content-Language: en-US To: "juzhe.zhong@rivai.ai" , Richard Biener , "Kito.cheng" References: <20230530060621.31449-1-kito.cheng@sifive.com> <87B2E2DEA59DF7D1+20230530154530505119343@rivai.ai> From: Robin Dapp In-Reply-To: <87B2E2DEA59DF7D1+20230530154530505119343@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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: >>> but ideally the user would be able to specify -mrvv-size=32 for an >>> implementation with 32 byte vectors and then vector lowering would make use >>> of vectors up to 32 bytes? > > Actually, we don't want to specify -mrvv-size = 32 to enable vectorization 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 = 128bit. > However, LLVM doesn't need to specify the vector length, and the codegen can run on any CPU with RVV  vector-length >= 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 == fixed vlmax). This patch assumes everything is fixed for optimization purposes and then switches over to variable-length when nothing can be changed anymore. That 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 than what we would have for pure VLA? Regards Robin