From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 362763853812 for ; Fri, 12 May 2023 13:08:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 362763853812 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-ej1-x62d.google.com with SMTP id a640c23a62f3a-965e4be7541so1667333366b.1 for ; Fri, 12 May 2023 06:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683896909; x=1686488909; 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=tKcSYqKrta9xxJNkSgkTLGfB0M7f3EvP8a9VobdvRbo=; b=rbxd5tNPHtv2G7OP1rgbuC735b9uWayuovDqBA5C5z/SH9NKujlMWif3CH0TwWAwJ+ wH7jqab0UgvGU61KhhWIseAPR9acPCPBC4ACY6R3516UB4FdZOsfUKEcxmy4eEtY54Wk dhIFzvfwMtHd6d4/OJgg/VUtB4YcMpcdP0+ItGroj5ImV2J1djY1tIq58km3oKmnI4FU mBIgERGQuW1N/MNb0Gh7tpPn1cwot+87OL8KY9ieSZXXajyLda47ayU43CzaHfqOT1J0 pV/hvzuua6Xc3pQRuGU1cEz7hWbYDpN84HOVGuEQGALChZZWEE4ixTm6WsyUt2e5ogr9 Knfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683896909; x=1686488909; 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=tKcSYqKrta9xxJNkSgkTLGfB0M7f3EvP8a9VobdvRbo=; b=YldZ0ewslJglGITd8kyuXBE3vGFIw0/8ti9WPJmrlvTF1JvbzxQcl/giO+LjkbfgeJ xkXk5i41UAPgYD+6tynSLZulDcO5ZDNwH1RoO6gSeo3tRYQY9a7MbMxUOYp+hkJa2svE /Sttka9b0/pR9OH2bt5uaWzz8qtgY575fiYXHE8DaLaTrumcEEFroPzmJlsFrVY33MOV 2OhP80uBjhCBVkAsn5NGi/WZ1VXAn/vsM/hcNltNlKNkdeYgn9u8ad/SLKuO4QT1x+Xd GvsuQZBC5PrylvpM3fYEhfipYvW+c/JNBQ4OTWtBNdlKhucbnJgN/K7x29JH+QCRInte KEsA== X-Gm-Message-State: AC+VfDx05+O9RenqVx9aqTR+si/X+X+Mu5NSVSUyjKNMnxdKYrlUWmK4 /rPRAKv8yhR//Us7CzSJgP8= X-Google-Smtp-Source: ACHHUZ65uf3Pamf9fiESigpSNUpn4bFOXbrKjkwG/FzqrzOUq/fix34cUJgxeG1vlRHaO5lPdYParA== X-Received: by 2002:a17:907:3e82:b0:966:2aab:ae5c with SMTP id hs2-20020a1709073e8200b009662aabae5cmr20668351ejc.38.1683896908439; Fri, 12 May 2023 06:08:28 -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 n4-20020a170906688400b00965f98eefc1sm5421433ejr.116.2023.05.12.06.08.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 06:08:28 -0700 (PDT) Message-ID: <04913d9d-ec3d-26ce-27ac-06ba9a47a8aa@gmail.com> Date: Fri, 12 May 2023 15:08:27 +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, kito.cheng@gmail.com, palmer@dabbelt.com, jeffreyalaw@gmail.com Subject: Re: [PATCH] RISC-V: Using merge approach to optimize repeating sequence in vec_init Content-Language: en-US To: juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org References: <20230512104412.170581-1-juzhe.zhong@rivai.ai> From: Robin Dapp In-Reply-To: <20230512104412.170581-1-juzhe.zhong@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 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, in general LGTM, just minor nits and comments. > - void set_len_and_policy (rtx len, bool force_vlmax = false) > - { > - bool vlmax_p = force_vlmax; > - gcc_assert (has_dest); > + void set_len_and_policy (rtx len, bool force_vlmax = false, bool ta_p = true, > + bool ma_p = true) > + { > + bool vlmax_p = force_vlmax; > + gcc_assert (has_dest); Indentation? > m_inner_mode = GET_MODE_INNER (mode); > - m_inner_size = GET_MODE_BITSIZE (m_inner_mode).to_constant (); > + m_inner_size = GET_MODE_BITSIZE (m_inner_mode); > + m_inner_units = GET_MODE_SIZE (m_inner_mode); I find it a bit misleading to call this units here. Granted it's an inner mode (i.e. referring to "bytes") but in the context of vector modes I'm likely to think of a vector "unit" or lane. What about m_inner_size_bytes or m_inner_size_units? > +bool > +rvv_builder::repeating_sequence_use_merge_profitable_p () > +{ > + return repeating_sequence_p (0, full_nelts ().to_constant (), npatterns ()) > + && inner_units () <= UNITS_PER_WORD > + && 3 * npatterns () < full_nelts ().to_constant (); > +} Appreciate the explanatory comment and number of instructions is good for now. In the future and given the different uarchs we will want a proper costing comparison. > +/* Get the mask for merge approach. > + > + Consider such following case: > + {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b} > + To merge "a", the mask should be 1010.... > + To merge "a", the mask should be 0101.... > +*/ Second line should be "b". > +/* Emit merge instruction. */ > + > +static void > +emit_merge_op (rtx dest, rtx src1, rtx src2, rtx mask) > +{ > + insn_expander<8> e; > + machine_mode mode = GET_MODE (dest); > + e.set_dest_and_mask (NULL_RTX, dest, GET_MODE (mask), true, true); > + e.add_input_operand (src1, mode); > + if (VECTOR_MODE_P (GET_MODE (src2))) > + e.add_input_operand (src2, mode); > + else > + e.add_input_operand (src2, GET_MODE_INNER (mode)); > + > + e.add_input_operand (mask, GET_MODE (mask)); > + e.set_len_and_policy (NULL_RTX, true, true, false); > + if (VECTOR_MODE_P (GET_MODE (src2))) > + e.expand (code_for_pred_merge (mode), false); > + else > + e.expand (code_for_pred_merge_scalar (mode), false); > +} Looks a lot like binop. Might need another round of wrappers soon :) Regards Robin