From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id F2AB03858D35 for ; Mon, 2 Oct 2023 08:26:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F2AB03858D35 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-x530.google.com with SMTP id 4fb4d7f45d1cf-52fe27898e9so22342632a12.0 for ; Mon, 02 Oct 2023 01:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696235163; x=1696839963; darn=gcc.gnu.org; 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=Ur2vXJG7AEQlo+dFbdv0hqiCszAzO/7SKEOt8IYjg6A=; b=WbK330Dr5WWd+pyGZ9y6djd4CVtobD2MB5roWHQCd/Z0POJfjs7zFyVFNViZ8K8BQ5 KB08FhpgjgitnNj4PnVV2Tdq5IEVzPQxbLwb6vW5ZQAZ2tParf96siuq8EM4zeQySP1F 0POdAbPHF1inO+QP4GOaSzh2Iw1nF8jeU1WT9PpDg5P8/WzC1SzFt/szpoymyFIZTAtp NWvRV/1i+DCrMWEq137qSRfydNSDa64ZN+ScjmxCBEywsLW3V0fLuLak5TbDTB9Y1hKP +FQsMLl/xeUBvuoLmW+j9bXnY+tur+DV/l4e/wFsAB0lWnTMQ0HbGhOH++IDwH8wD+6H posA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696235163; x=1696839963; 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=Ur2vXJG7AEQlo+dFbdv0hqiCszAzO/7SKEOt8IYjg6A=; b=mUAt+oEazWhWwRRAEj/3cWnbcLiRzInaoJbTwK/mqYhhMkiKxS5gP9Kuzvg3M7iS8W 6A0fEaDtuQT2+Mg6gWtHrXrDVrkviCc1Yn8Hi+AREjW3N5MLxCPu9bzYTnxTyzePkz3C terDvxE1K3Ns3ffQB0zOVzY816EjU4KtVkHO7cgz0LG9TBmfV9cSePEUV34O22xOi8cK a+Qhoob6rfard5iwiSXpxmUaS+GJ1CZI/WeQktwae/oR8XTIULCgUxMIaDuwCQ5UOddQ 1pYPihR0W4dJ/tQHw3YLY5vcYpzg+P1yTYk0arK/dox83c6nuEjvatk/LSisSQQkLWBq RyPw== X-Gm-Message-State: AOJu0YzorDZpxZHsh25X/HlY2zd3JJAifJxN2BZPQim7acqJVvorzPC6 RF78+vnRcd6EsiOSKG9zMAA= X-Google-Smtp-Source: AGHT+IHYU9xnWnxaabQSWZVONqeyAnDgdwyOR1WVZY2n7Cs+dC0soD1zmTwyoGqgKWyQotD6sHf5nQ== X-Received: by 2002:a17:906:cc13:b0:9ae:4d6d:ba51 with SMTP id ml19-20020a170906cc1300b009ae4d6dba51mr9599100ejb.21.1696235163247; Mon, 02 Oct 2023 01:26:03 -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 f4-20020a5d50c4000000b0031fa870d4b3sm27399165wrt.60.2023.10.02.01.26.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Oct 2023 01:26:02 -0700 (PDT) Message-ID: <47a52409-6489-a755-5195-ea110c4cb145@gmail.com> Date: Mon, 2 Oct 2023 10:26:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Cc: rdapp.gcc@gmail.com, "juzhe.zhong@rivai.ai" , "Wang, Yanzhang" , "kito.cheng@gmail.com" Subject: Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook To: Jeff Law , "Li, Pan2" , "gcc-patches@gcc.gnu.org" References: <20230821072627.3984748-1-pan2.li@intel.com> <995842b2-2765-24d5-466e-4588dcdcc48e@gmail.com> <951fced9-f798-f9b6-7827-14447a93d1c9@gmail.com> Content-Language: en-US From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.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 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: > Conceptually the rounding mode is just a property. The call, in > effect, should demand a "normal" rounding mode and set the rounding > mode to unknown if I understand how this is supposed to work. If my > understanding is wrong, then maybe that's where we should start -- > with a good description of the problem ;-) That's also what I what struggled with last time this was discussed. Normally, mode switching is used to switch to a requested mode for an insn or a call and potentially switch back afterwards. For those riscv intrinsics that specify a variable, non-default rounding mode we have two options: - Save and restore before and after each mode-changing intrinsic fegetround old_rounding fesetround new_rounding actual instruction fesetround old_rounding) - Have mode switching do it for us (lazily) to avoid most of the storing of the old rounding mode by storing an (e.g.) function-level rounding-mode backup value. The backup value is used to lazily restore the currently valid rounding mode. The problem with this now is that whenever fesetround gets called our backup is outdated. Therefore we need to update our backup after each function call (as fesetround can of course be present anywhere) and this is where most of the complications come from. So in that case the callee _does_ impact the caller via the backup clobbering. That was one of my complaints about the whole procedure last time. Besides, I didn't see the need for those intrinsics anyway and would much rather have explicit fesetround calls but well :) Having said that, it looks like Pan's patch just tries to move some of the dirty work from the backend to the mode-switching pass by making it easier to do something after a call. I believe I asked for that back in one of the reviews even? Regards Robin