From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id ED3FE3858D20 for ; Fri, 28 Jul 2023 10:05:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED3FE3858D20 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-x630.google.com with SMTP id a640c23a62f3a-99bcfe28909so265820866b.3 for ; Fri, 28 Jul 2023 03:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690538725; x=1691143525; 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=yIabxJtKSAeMudxWFraJJ8dbjAPq+p6iivOEj6THGHY=; b=iUFboJGoi1AbQx5EgFUzGVtBIvLywGy/HN3MEFrEDCa/+DQsR/Y4Slnb+KWXaC94YL zcb4DFAWSAFUZKxWAakbUxWk7Nh4TfHM5WOHwrR+BkNTojhzA2mnl511VonrJssa3xYQ PngzWzLBe2lhtlC5McgSbsNcI6fZ12pU5ynsLz1a6brK5yAfcD0w9APs5FbhMWQ/txrO ENZVKN+611g023KrPwyS8Heyjrnr/9L246MclkLIIolpL4rJ1UR05m2fn688vQTxBcfr 9KLUbYGZab8smYOv0sQ4KvSDBQMHjkGb/D/58bLcTfVsEw4o52ulzRq+yN10w6+mp6u3 MdpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690538725; x=1691143525; 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=yIabxJtKSAeMudxWFraJJ8dbjAPq+p6iivOEj6THGHY=; b=FuFHr9pgX+GLbj4qlcDou9hVl3CD+GoRBx+RR6ri01Oou2F3SNMp1/+mXTM9JzFK7e ruOZMNgXpyRhH+IgFULxh4GDC8tDYpLX4gVr+POHcjC062pwrqzQCMM/q5dhwHjsrECJ 8BKhDe6lBpTu/2ttl9EoXNpmMx4gsu1+WcKlMRJvR8DEIEABkOGQeoZ62FzbdDTVEve1 Oxao6GB7bj8esVe5dX0cIaCh8cfDlkh+i9M1sSZXvkAmGVnJ9n/C3Jm2Edvn2yIYtCfa nbzcXuNPAuQB1iiikeqmv/JjaRYBNf4AcsRWHvyELRAf2/kkFMZthrQa53xVO/O7RN94 l/4A== X-Gm-Message-State: ABy/qLbVo1x7s3IIxxs5XYIScP1mk796fYgU8MmY5UXfzQwVdqkyjFtr 8x7MNuQm5B581xNFUCE1S+mmQnYj8ODjxw== X-Google-Smtp-Source: APBJJlEXKAvBO3XEtWD5VQ+ipYL1dim5FDHWzTQFcMNV7BmA2BbE70q4GeAshH2NKEhdvHOOU6OASw== X-Received: by 2002:a17:906:8453:b0:993:d75b:63ea with SMTP id e19-20020a170906845300b00993d75b63eamr2085464ejy.16.1690538724663; Fri, 28 Jul 2023 03:05:24 -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 x20-20020a1709065ad400b00988be3c1d87sm1867456ejs.116.2023.07.28.03.05.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jul 2023 03:05:23 -0700 (PDT) Message-ID: Date: Fri, 28 Jul 2023 12:05:21 +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 v8] 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> <20230728011521.3280522-1-pan2.li@intel.com> Content-Language: en-US From: Robin Dapp In-Reply-To: <20230728011521.3280522-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, thanks for your patience and your work. Apart from my general doubt whether mode-changing intrinsics are a good idea, I don't have other remarks that need fixing. What I mentioned before: - Handling of asms wouldn't be a huge change. It can be done in a follow-up patch of course but should be done eventually. - The code is still rather difficult to follow because we diverge from the usual mode-switching semantics e.g. in that we emit insns in mode_needed as well as in mode_set. I would have preferred to stay close to the regular usage, document where and why we need to do something different and suggest future middle-end improvements to solve this more elegantly. - I hope non-local control flow like setjmp/longjmp, sibcall optimization and maybe others work fine. I didn't see a reason why not but I haven't checked very closely either. - We can probably get away with not annotating every call with an FRM clobber because there isn't any pass that would make use of that anyway? As to my general qualm, independent of this patch, quickly summarized again one last time (the problem was latent before this specific patch anyway): I would prefer not to have mode-changing intrinsics at all but have users call fesetround explicitly. That way the exact point where the rounding mode is changed would be obvious and not subject to optimization as well as caching/backing up. If at all necessary I would have preferred the LLVM way of backing up, setting new mode, performing the instruction and restoring directly after. If the initial intent of mode-changing intrinsics was to give users more control, I don't believe we achieve this by the "lazy" restore mechanism which is rather an obfuscation. Pardon my frankness but the whole mode-changing thing feels to me like just getting a feature out of the door to solve "something" /appease users than a well thought-out feature. It doesn't even seem clear if this optimization is worthwhile when changing the rounding mode is prohibitively slow anyway. That said, if the current status is what the majority of contributors can live with, I'm not going to stand in the way, but I'd ask Kito or somebody else to give the final OK. Regards Robin