From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 0FEA53858D35 for ; Wed, 26 Jul 2023 21:01:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0FEA53858D35 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-x52e.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so397801a12.0 for ; Wed, 26 Jul 2023 14:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690405311; x=1691010111; 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=TX20XrVBm5kH3/1rOrsp2sBwpnHRaUNLkM/32C1uumk=; b=IQ0hsCBduiHyq0o+Rn518S0lUyi5WqbElvHY7+xhxdXUpwEVqg5vM6tjZKEdO1Lt1G +UejQfkUlQwoZ8VG8xk89P683Ur3oGPlKqo82eFx50dFgS0kqumwylw/WApe4vdn5ai5 o4xr+cKUNgfavAgfErl99PaeBhuTQg9t8skD/V96I2HRB3ESRlBXXIn3iBK9WyW0Amf2 ka8tW2JYW57mcDThwBonc+a8hHh2SE5XPNMDm8+p08umZslBapq2ffL/GNT6F76WRkAe 4MHFTgmNQp80SYnXL8qJSA2+UdA+hV5rIbrpih3YDYEIhG495PimWzd54CpBTQKaFFKm VA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690405311; x=1691010111; 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=TX20XrVBm5kH3/1rOrsp2sBwpnHRaUNLkM/32C1uumk=; b=lx+kT9Jeb6nBr+XueaJFGKx9K2MpzjJF9HRA5jr+VtZjrUBgLG4XJqeSgnKRWwFx5M wlIU1orzi4e7cYxc+EBxQxGFltWRd2yVsZkdy3uq3F++Kc58JcnOpCRaIohWaHGf8ZWs gK8nTeO7jbJJmxKGeVlnAT2p9glxHNI5pQ1StBoR2ob2/1HiKehD+9fpMS9tNjjdBM5K yUXeIKJ4FWlP8PSxIlGyS6C7q6eWYjFuHayKK2lykcjMokjHEW+VAc9cASTYQ93ztBD6 w1LPdPULTtG0badrRrEgm/LgZuxtynzjfygDzOTMbk3yGCmt96dEcq0lvLYAMrvg8bUZ hvDg== X-Gm-Message-State: ABy/qLZxcJW/lGWT9exCiZuXVew1o7SGQqIJycJZCewwmk2fIMwxXfnO Lt5IRhZdrlBTd4sRKNUMpYg= X-Google-Smtp-Source: APBJJlH4UVugYUs2kIWgvW1FwrYQOZEsZICmhfk5wGSBh1kp/3u9kf/4KZ2ssO5hckMKdbJ8LWnVrQ== X-Received: by 2002:aa7:d284:0:b0:51e:227c:9492 with SMTP id w4-20020aa7d284000000b0051e227c9492mr186931edq.20.1690405311133; Wed, 26 Jul 2023 14:01:51 -0700 (PDT) Received: from [192.168.1.24] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id u11-20020a056402064b00b0051dfa2e30b2sm9160160edx.9.2023.07.26.14.01.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jul 2023 14:01:50 -0700 (PDT) Message-ID: <809594de-f00f-7229-820e-17b543e5de2a@gmail.com> Date: Wed, 26 Jul 2023 23:01:49 +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, "kito.cheng" , gcc-patches , "Wang, Yanzhang" Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding Content-Language: en-US To: "Li, Pan2" , =?UTF-8?B?6ZKf5bGF5ZOy?= References: <20230719032822.85817-1-pan2.li@intel.com> <20230725055156.595718-1-pan2.li@intel.com> <2a9db9ea-ba9e-264c-fe2f-c44bb8f9d580@gmail.com> <63471C6E126E44CF+D1CEA4C9-0050-43CD-8DE3-26EBD7AEE6DA@rivai.ai> <37662fdd-6878-54ed-eba9-2eb601308270@gmail.com> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.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: > I would like to propose that being focus and moving forward for this > patch itself, the underlying other RVV floating point API support and > the RVV instrinsic API fully tests depend on this. Sorry, I didn't mean to ditch LCM/mode switching. I believe it is doing a pretty good job and we should continue to use it. The changes in this patch (and the ones before) seem to follow a certain plan but, at least to me, it only became obvious with this last patch. We're already lost in details when the fundamentals are not agreed upon yet. It would have been easier to discuss (and quicker to "focus and move forward") if the cover letter had already laid out the possible alternatives and their respective pros and cons instead, even more so when many things depend on it. Still, three things: (1) I'm fully on board with restoring the rounding mode after changing it implicitly via an intrinsic (guess everybody is). This needs to be done anyway and also implies a costly fsrm. "Forcing" it before a call can most likely be treated like any other DYN instruction requiring the "entry" rounding mode. Likewise restoring at function exit. The placement of the necessary restores LCM can handle reasonably well. (2) What I'm not entirely happy with is assuming that every function call can _change_ the rounding mode and we always need to re-backup it. I realize that it might be a necessary evil because all other options are worse. Assuming no change through a call makes properly using fesetround-like calls impossible as they would clobber our backup register. This patch takes the approach to re-backup after every call. As-is, wouldn't we also need to make sure that GCC knows that a call clobbers the FRM (via clobber: (reg:SI 69 frm)) so we don't accidentally move something beyond it? (3) One other option I can think of is "localized" re-backup of the FRM before each mode-changing intrinsic. That would result in redundant save/restore insns around those than with the call proposal and therefore likely worse. Whether that is relevant when the restore is slow anyway might be debatable. Yet, it's not a given that storing the FRM always is an in-order operation, it has just mostly been that way historically. Another conceivable option (and maybe even the right thing to do) would be special treatment, like a propagating flag etc. for fesetround. That's common code and not likely to happen or land soon, though. Regards Robin