From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id EEE153858D20 for ; Wed, 12 Jul 2023 14:24:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EEE153858D20 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-wr1-x435.google.com with SMTP id ffacd0b85a97d-3143ccb0f75so7995747f8f.0 for ; Wed, 12 Jul 2023 07:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689171874; x=1691763874; 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=IEbej/LAddX8Eiw3jB0bpiM9q8SuQccVt7clJu2FbMw=; b=O13ndQDViV/QG40jI7RbORWGH49eRr8k5odiQwXpzwnMOHyDRVxy3QUEVdkLeDKgN/ 4fiKvTajY76OknkyWdc6Ih2HMahllQUNucIetTCxTYPYY/YiuGIVU3Fxnpeo/dSocik4 DPIGbIz/mDTBHvBxspwTPYy5AkkdPnZfiG9CLl1/MX9BgHD4gPaJCqdJeNF+8CDvAndH +KpANGuRbdE+fC4TZXbnQcDqrtntuj+mbLoamzzIVWa7CARtNMJ5J0EdIR9KOi/j9qQ0 1tc5W7IRxxIPn0A7mqm1Y2OgQElRimOkuEWuqrjgn37XiAo5aXd6uD6uSf3ECE7FXRlq e3Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689171874; x=1691763874; 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=IEbej/LAddX8Eiw3jB0bpiM9q8SuQccVt7clJu2FbMw=; b=NQcMRc3xNtQha9tYihrIsOCt2zin5DfARFkTgeVy712vxq3fDVlYfTsd6Uz6aZsfkk gPkN/UBY4+CaqJKIuJiqZeV7SrNjaT+xShRCEoiKoVZh+3wXY8uMk2KXq8fFWbKixDp7 bbYf2JqChE1LAPEDgZBKTrY4ec9lE/O5UfDtOPkli2+5B7vdJ8wn98SwuAWjHNGQWul/ Uwl6kc6po5Pm+GcDF6x6HYK0I702eei5wA3zAxDzaRyE/Y7gdzrBQb8RpOiGqCAsQRz4 ajmO7Pdv2s5AHmwzFaHFRNYD7nFToDi8eO5h3UDglHvQth4FR/Ci1Z7gSNo1//ZsnzOW YE0w== X-Gm-Message-State: ABy/qLZHsR+aHy87vGviKQml4v/XBolNAQ4W6+0YJFTyvlA2cpdGhJRI PbdjpXBepyCB9qEZ64eiKBI= X-Google-Smtp-Source: APBJJlErJ5/YxzDI5LVjheSr/BdJXqDjCVht6GNKa6vGPnSO8vWyREu8Wl9UtDG5r7xqLJP1ccA40w== X-Received: by 2002:a5d:4203:0:b0:314:22ea:4ee7 with SMTP id n3-20020a5d4203000000b0031422ea4ee7mr20684774wrq.33.1689171873715; Wed, 12 Jul 2023 07:24:33 -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 y3-20020a056000108300b003141f96ed36sm5263796wrw.0.2023.07.12.07.24.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 07:24:33 -0700 (PDT) Message-ID: <2e89d166-50d3-e7b9-2824-97beb3686042@gmail.com> Date: Wed, 12 Jul 2023 16:24:32 +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, jeffreyalaw@gmail.com Subject: Re: [PATCH] RISC-V: Support COND_LEN_* patterns Content-Language: en-US To: Juzhe-Zhong , gcc-patches@gcc.gnu.org References: <20230712044424.75724-1-juzhe.zhong@rivai.ai> From: Robin Dapp In-Reply-To: <20230712044424.75724-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, > +/* Return true if the operation is the floating-point operation need FRM. */ > +static bool > +need_frm_p (rtx_code code, machine_mode mode) > +{ > + if (!FLOAT_MODE_P (mode)) > + return false; > + return code != SMIN && code != SMAX; > +} Return true if the operation requires a rounding mode operand. Maybe also call it needs_fp_rounding? > + if (need_frm_p (code, mode)) > + emit_nonvlmax_fp_tu_insn (icode, RVV_BINOP_MU, ops, len); > + else > + emit_nonvlmax_tu_insn (icode, RVV_BINOP_MU, ops, len); > + } This feels like we could decide it inside emit_nonvlmax_tu_insn. Same for without _tu. But let's keep it like this for now in order not to stall progress. > +/* Implement TARGET_PREFERRED_ELSE_VALUE. For binary operations, > + prefer to use the first arithmetic operand as the else value if > + the else value doesn't matter, since that exactly matches the SVE > + destructive merging form. For ternary operations we could either > + pick the first operand and use FMAD-like instructions or the last > + operand and use FMLA-like instructions; the latter seems more > + natural. */ What's FMLA? That's SVE I suppose and ours is fmacc? Apart from that fine from my side, thanks for supporting this. Regards Robin