From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 209323858D1E for ; Fri, 23 Dec 2022 10:05:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 209323858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D086C1FB; Fri, 23 Dec 2022 02:06:01 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0F25D3FA32; Fri, 23 Dec 2022 02:05:19 -0800 (PST) From: Richard Sandiford To: Alexander Monakov via Gcc-patches Mail-Followup-To: Alexander Monakov via Gcc-patches ,"Jose E. Marchesi" , Alexander Monakov , qing.zhao@oracle.com, richard.sandiford@arm.com Cc: "Jose E. Marchesi" , Alexander Monakov , qing.zhao@oracle.com Subject: Re: [PATCH V2] Disable sched1 in functions that call setjmp References: <20221222173208.13317-1-jose.marchesi@oracle.com> <53b93d7e-a157-9116-d07a-4d51cd43d205@ispras.ru> Date: Fri, 23 Dec 2022 10:05:18 +0000 In-Reply-To: <53b93d7e-a157-9116-d07a-4d51cd43d205@ispras.ru> (Alexander Monakov via Gcc-patches's message of "Thu, 22 Dec 2022 20:56:18 +0300 (MSK)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-38.2 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Alexander Monakov via Gcc-patches writes: > On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote: > >> The first instruction scheduler pass reorders instructions in the TRY >> block in a way `b=true' gets executed before the call to the function >> `f'. This optimization is wrong, because `main' calls setjmp and `f' >> is known to call longjmp. >> >> As discussed in BZ 57067, the root cause for this is the fact that >> setjmp is not properly modeled in RTL, and therefore the backend >> passes have no normalized way to handle this situation. >> >> As Alexander Monakov noted in the BZ, many RTL passes refuse to touch >> functions that call setjmp. This includes for example gcse, >> store_motion and cprop. This patch adds the sched1 pass to that list. >> >> Note that the other instruction scheduling passes are still allowed to >> run on these functions, since they reorder instructions within basic >> blocks, and therefore they cannot cross function calls. >> >> This doesn't fix the fundamental issue, but at least assures that >> sched1 wont perform invalid transformation in correct C programs. > > I think scheduling across calls in the pre-RA scheduler is simply an oversight, > we do not look at dataflow information and with 50% chance risk extending > lifetime of a pseudoregister across a call, causing higher register pressure at > the point of the call, and potentially an extra spill. > > Therefore I would suggest to indeed solve the root cause, with (untested): > > diff --git a/gcc/sched-deps.cc b/gcc/sched-deps.cc > index 948aa0c3b..343fe2bfa 100644 > --- a/gcc/sched-deps.cc > +++ b/gcc/sched-deps.cc > @@ -3688,7 +3688,13 @@ deps_analyze_insn (class deps_desc *deps, rtx_insn *insn) > > CANT_MOVE (insn) = 1; > > - if (find_reg_note (insn, REG_SETJMP, NULL)) > + if (!reload_completed) > + { > + /* Do not schedule across calls, this is prone to extending lifetime > + of a pseudo and causing extra spill later on. */ > + reg_pending_barrier = MOVE_BARRIER; > + } > + else if (find_reg_note (insn, REG_SETJMP, NULL)) > { > /* This is setjmp. Assume that all registers, not just > hard registers, may be clobbered by this call. */ +1 for trying this FWIW. There's still plenty of time to try an alternative solution if there are unexpected performance problems. Richard