From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 5098F3858D3C for ; Tue, 25 Jul 2023 14:12:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5098F3858D3C 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-lj1-x229.google.com with SMTP id 38308e7fff4ca-2b734aea34aso80866201fa.0 for ; Tue, 25 Jul 2023 07:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690294348; x=1690899148; 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=KqY46CwXHFgKcGU2RrqT68gdo0Nq/UwRrNgqrpfVALc=; b=al6WjsAO08wRvV3vuTWYNTaqkdwYoT2oTiv4APBaegpF0VKw4l6OL6NO8223K+D+Ch I08AW6BPRkXLv1u+p8Uus+KT7qk1TOMgx0Lv++hLpangdG+uMzX6Er20i9f7kGqgqDEV IvRCUvHSrGx9wO7Qj1NrLI4KKv4K3jHhbc04TEVH+xoE0C/+3yiwWRq7dCfPODbMSjGO zvADGE0pEOnERmtHfAH/vQ3EgPJqB0cPuDYGGx/m4clVTeRTTXsRAtiWeUJs4l4ySGsh SDpWsSbOm8nsqOMjX6IZ68S58zi4+iALrfAdNzKJqi1egyMkf3rS3I7mM4ncesF49kEK S9cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690294348; x=1690899148; 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=KqY46CwXHFgKcGU2RrqT68gdo0Nq/UwRrNgqrpfVALc=; b=VC4eIiyNE1dQmmJDPBbg/IF4qmrlTboAK/pWjInfQF/7X8d/Zfb07N6qRWqUzoh46w /uJhQ5553ogSwSU8+Zav6toBliTFfn/4s2PTracvf1TFtfU4NQISRMKgtL9fpa1be6DQ sUusVbXGrs0vZ9PjcUdK6QbNG0usO5OSE14tq1wu4ITTPub4k4pE/HSRhTyo3p6ALU01 Kz9asMUYrPOmwf8J5qaOsBVQo51wWi+umWEFRHU1IIEgboSgdLTmaQKklvtgOpQWDGnh ojjbg/gAQW/whEM48gMgfC74ENKIjE86V2qUQIGsagVuQGH6k/IzvNsWatxx5Vcxxeke cxnQ== X-Gm-Message-State: ABy/qLZY0FPgkS2DOOKQcOoFuc627UjZVXIL4CXTOunhAKeIL2uB7VsZ LwPW3xH2/1wT8Jg6nStMYWE= X-Google-Smtp-Source: APBJJlFmfZh94ak4MtJYyHLKeve7dxAn17obk4sbUu+WgW83tDS3uszbBujeC9NqOFM6YzhSp/0+wA== X-Received: by 2002:a2e:9204:0:b0:2b6:cc93:4ecb with SMTP id k4-20020a2e9204000000b002b6cc934ecbmr9714657ljg.43.1690294348042; Tue, 25 Jul 2023 07:12: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 ks27-20020a170906f85b00b0097404f4a124sm8276461ejb.2.2023.07.25.07.12.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jul 2023 07:12:27 -0700 (PDT) Message-ID: <2a9db9ea-ba9e-264c-fe2f-c44bb8f9d580@gmail.com> Date: Tue, 25 Jul 2023 16:12:26 +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, "gcc-patches@gcc.gnu.org" , "juzhe.zhong@rivai.ai" , "Wang, Yanzhang" Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding Content-Language: en-US To: Kito Cheng , "Li, Pan2" References: <20230719032822.85817-1-pan2.li@intel.com> <20230725055156.595718-1-pan2.li@intel.com> From: Robin Dapp In-Reply-To: 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: > The call fesetround could be any function in practice, and we never > know if that function might use dynamic rounding mode floating point > operation or not, also we don't know if it will be called fesetround > or not. > > So that's why we want to restore before function call to make sure we > don't break rounding mode for any inner function, also backup the frm > after function call can handle the case if the inner function has > changed global rounding mode. Ah, that clarifies things a bit. Yes, I figured - the function is opaque anyway. I think we're touching a general question here, I suppose there already have been discussions on the LLVM side about this? What about ABI implications? By saving and restoring before and after a function call we assume the FRM register to be call clobbered instead of letting the function/call save/restore it. Apart from fesetround I can't imagine many cases where we would want to re-use the rounding mode from inside a call so it might be advantageous to leave the burden of saving/restoring to the callee. But that's a similar discussion as with the vector ABI so I don't expect a conclusion ;) Regards Robin