From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id 9E02C387442A for ; Fri, 7 Jul 2023 12:34:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E02C387442A 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-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3fbd33a57ddso20038585e9.1 for ; Fri, 07 Jul 2023 05:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688733248; x=1691325248; 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=HloE1oFupXUD32vRQhiQjyKUCCSx4dtBOTHSmO2WevI=; b=bzzLS2mhuPU0Do1VBX4sEmg7JMsno0PZrs4AZx9+2quigYW8Hyop4Bh7uN8Mw3Lu+e 81Ep0ViTuOSGB5NkzE6DYnwBodYIAh0V+bqJC24Qpeb9+B2HlZjQs8dEI9jVhzy9fbO4 Xy041RzcsSUTFb2XMEBePXvpkHJgADH3HoEEBaoYg35BLEFyCn/1vHgWgqWSJA2K53Py l0w5OOprCQe3SiG4cocf54X7HQ5msRgWKTpvBxuTxQxLxqztNiolmlfHqiw1iIEolQ/m aJga/JJG4HLFVNh9e7Iqp+iVj54nvUpHQUKe/NUIgQgC2i+5yQLFcXy87/MTZ92IMqSb 2byA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688733248; x=1691325248; 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=HloE1oFupXUD32vRQhiQjyKUCCSx4dtBOTHSmO2WevI=; b=IBPnUy4S/MjS6qlqip5XPPao6+5FHoNukKajsDhTQBMcngTWg4+3kB9ZEDb44kRV3l qcULrhiYSpg7N+F+Xis8Rsx1AY5w773xnFX5ogif0+BwajH1qBADT4VTvFclWY1ylc8i j+xj56/MH/uMpyBiWmnfOSI8uAEJTd5CasWe5Knli+HyPbVB/Fil8s15O9lGsAUaqEgv GGnRQ9fcLAlTXjzb3TmfTeIwd5NpJ2zL3EdVlT1QBwlFcDNRPoAv3aTmhp2TbjzPH2fP K2rZNBpPG//9vaAeF0defVyO+oXcYF9X4qFcg7zd/CpmdM9rYOlevLNtyxqYmVkaB2KG HVag== X-Gm-Message-State: ABy/qLa86JT+EKtvjI1ryHLr0bkHiei/BrEFG4GAbnSCu99v8dSqEzOf OiLl3nzJdYhavpJgb+hMOLI= X-Google-Smtp-Source: APBJJlH/TzYmcfAQADjUiX3p6PQe9KA2gkUnbmKPv5xB5T1djWxNuRuHfQoLdqR491flv1uo6Pwqcw== X-Received: by 2002:adf:dd4b:0:b0:314:182a:3d96 with SMTP id u11-20020adfdd4b000000b00314182a3d96mr3773875wrm.28.1688733247908; Fri, 07 Jul 2023 05:34:07 -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 v2-20020a5d6102000000b003144bfbd0b3sm4361549wrt.37.2023.07.07.05.34.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jul 2023 05:34:07 -0700 (PDT) Message-ID: <217c769f-d97c-e381-1b66-542b563db12b@gmail.com> Date: Fri, 7 Jul 2023 14:34:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Cc: rdapp.gcc@gmail.com, kito.cheng@gmail.com, kito.cheng@sifive.com, palmer@dabbelt.com, palmer@rivosinc.com, jeffreyalaw@gmail.com Subject: Re: [PATCH V4] RISC-V: Support gather_load/scatter RVV auto-vectorization Content-Language: en-US To: Juzhe-Zhong , gcc-patches@gcc.gnu.org References: <20230707104847.271195-1-juzhe.zhong@rivai.ai> From: Robin Dapp In-Reply-To: <20230707104847.271195-1-juzhe.zhong@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 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: Hi Juzhe, thanks, the somewhat unified modulo is IMHO a more readable. Could probably still be improved but OK with me for now. > + if (is_dummy_len) > + { > + rtx dummy_len = gen_reg_rtx (Pmode); Can we call this is_vlmax_len/is_vlmax and vlmax_len or so? > + if (inner_offsize < inner_vsize) > + { > + /* 7.2. Vector Load/Store Addressing Modes. > + If the vector offset elements are narrower than XLEN, they are > + zero-extended to XLEN before adding to the ptr effective address. If > + the vector offset elements are wider than XLEN, the least-significant > + XLEN bits are used in the address calculation. An implementation must > + raise an illegal instruction exception if the EEW is not supported for > + offset elements. */ > + if (!zero_extend_p || (zero_extend_p && scale_log2 != 0)) Hehe I really thought we have a widening shift, well ;) I see, the zero extension refers to this part of the GCC docs "multiply the extended offset by operand 4;" and not to the RVV spec. You could clarify this then, saying that the RVV spec only refers to the scale_log == 0 case. The rest LGTM now, no separate revision needed for those nits. Regards Robin