From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 7A5223858D32 for ; Mon, 24 Jul 2023 10:28:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A5223858D32 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-x532.google.com with SMTP id 4fb4d7f45d1cf-51bece5d935so6449169a12.1 for ; Mon, 24 Jul 2023 03:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690194512; x=1690799312; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZWuXYWrPOFvZ8GsDYRulA6wW1DF+0reEfjLfuD2FJC4=; b=eeCYDWgyY8AIVBuMS87q5YJjsYq5Zs4ZaYnGcU+XpT42HsuHBwmJR4csHcj4y85sZf f41XDbZhL53cDzDXzxw3ziCEegWCB04DB1PcRZxfnZ1Wc9pmoTb0ztDwJWgIAM4UCDRJ /+90wMi9ncFvV9ootBGQH8W41Oev6FhKmc5uLtiuqRuBThBQ5xl19slJhiklGPyzFd6v UFc2pgAo3vsGd32x/M5lRKnB4mXtnNQaDXIuUtW8h5uXo+tXkJyVTE5ljpLdE3dkP6TV xW1gbg70EYAlYnAU3n5eKkkHZmnUmnBagUVZD1svFVnB4Yl8vWRS5E5DD4gYfUBTfjQy FqjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690194512; x=1690799312; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZWuXYWrPOFvZ8GsDYRulA6wW1DF+0reEfjLfuD2FJC4=; b=jAgCIhKXPTuHmMiJAzyo5ToOE/BcP1As6/kxR/Dqo3eQP+A0TCUsLAcpO4ggVb4hRs mmv8mmiSeiIYGayMMgcZhTxy0TjVXjYq/+x11bia53G66+ca3GtmgHgLD3w1KZNSTJNF ZBiZ4XajLrPPH7dFagxJuHV47zYXyeYP6gCu2flXhM0Dgv6xUAjSJi4jyuaA6LQhcbBM uRSNeaFiYpbciZNo4T9SBNpyr5uhL5yJBoWZ4p00lmPf1M+XGfuMT69d954vZf9WQakh VBDbS+JGe50cjOzyv1jAkCUwTJO5Xxn4TT1N1A4pJdBfHVhSrd/FbMNsLUsVr9BN8H1u WHKg== X-Gm-Message-State: ABy/qLbvHvCKB+1rqy76MCOgJyg64/wXOfIzMUaJ1wKD8/78pEo7rmsN +9Cy85nBCBkbVrxykdt1aew= X-Google-Smtp-Source: APBJJlGHuY4A9qhb+2xIiQQGvxoYKqm6l+5v5aY7T3z9TwIQj74A8wOLZwRAx5iyQxjV4e7s5/9pfw== X-Received: by 2002:a17:906:21a:b0:991:e3c4:c129 with SMTP id 26-20020a170906021a00b00991e3c4c129mr9843819ejd.69.1690194512411; Mon, 24 Jul 2023 03:28:32 -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 l2-20020a170906230200b00997e52cb30bsm6415054eja.121.2023.07.24.03.28.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Jul 2023 03:28:32 -0700 (PDT) Message-ID: Date: Mon, 24 Jul 2023 12:28:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: rdapp.gcc@gmail.com, juzhe.zhong@rivai.ai, kito.cheng@sifive.com, yanzhang.wang@intel.com Subject: Re: [PATCH v6] RISC-V: Support CALL for RVV floating-point dynamic rounding To: pan2.li@intel.com, gcc-patches@gcc.gnu.org References: <20230719032822.85817-1-pan2.li@intel.com> <20230724024209.3595212-1-pan2.li@intel.com> Content-Language: en-US From: Robin Dapp In-Reply-To: <20230724024209.3595212-1-pan2.li@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 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 Pan, > + for (insn = PREV_INSN (cur_insn); insn; insn = PREV_INSN (insn)) > + { > + if (INSN_P (insn)) > + { > + if (CALL_P (insn)) > + mode = FRM_MODE_DYN; > + break; > + } > + > + if (insn == BB_HEAD (bb)) > + break; > + } > + > + return mode; > +} Does prev_nonnote_nondebug_insn_bb help here? In general, we scan back here to the last insn and "recover" if it was a call? Why can't we set the proper value already before exiting the function? I guess the more general question is more towards call-clobbered or not? In this patch we assume the rounding mode is call clobbered and restore it ourselves. Has there been any kind of consensus on this? Intuitively I would have expected a function that requires a non-standard rounding mode to set and restore it itself. > + > +/* Insert the backup frm insn to the end of the bb if and only if the call > + is the last insn of this bb. */ > + > +static void > +riscv_frm_reconcile_call_as_bb_end (rtx_insn *cur_insn) > +{ > + rtx_insn *insn; > + basic_block bb = BLOCK_FOR_INSN (cur_insn); > + > + gcc_assert (CALL_P (cur_insn)); > + > + if (cur_insn != BB_END (bb)) > + { > + for (insn = NEXT_INSN (cur_insn); insn; insn = NEXT_INSN (insn)) > + { > + if (INSN_P (insn)) /* If there is one insn after call, do nothing. */ > + return; What about nondebug insns? Also maybe next_nonnote_nondebug_insn_bb helps? How about splitting the function in detection and emit? I.e. bb_ends_in_call (or so) and the emit part. That way it could be more obvious in "needed" what needs to be done. Are we handling sibcalls and tail calls properly here? In general I'm still a bit wary that we are checking mode != prev_mode but cannot really pinpoint why. I would have hoped that the generic code only calls us when this check is unnecessary and if not the "needed" hook should be adjusted. I also find it a bit odd to emit instructions when checking if another mode is needed. If what's required cannot be accomplished with the current common code, shouldn't we rather try to amend that? Regards Robin