From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id D673C3848034 for ; Mon, 26 Jul 2021 22:57:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D673C3848034 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 16QMt6H7000437; Mon, 26 Jul 2021 17:55:06 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 16QMt5L4000436; Mon, 26 Jul 2021 17:55:05 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 26 Jul 2021 17:55:05 -0500 From: Segher Boessenkool To: Jeff Law Cc: Richard Biener , "Bin.Cheng" , Eric Botcazou , Jeff Law , GCC Patches , "bin.cheng" Subject: Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch Message-ID: <20210726225505.GU1583@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 22:57:10 -0000 On Fri, Jul 23, 2021 at 10:27:37AM -0600, Jeff Law wrote: > On 7/22/2021 7:04 AM, Richard Biener via Gcc-patches wrote: > >On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches > > wrote: > >>Gentle ping. Any suggestions would be appreciated. > >So just to say something - does the existing code mean that any use of > >the alias info on prologue/epilogue insns is wrong? We have > > > > /* The prologue/epilogue insns are not threaded onto the > > insn chain until after reload has completed. Thus, > > there is no sense wasting time checking if INSN is in > > the prologue/epilogue until after reload has completed. */ > > bool could_be_prologue_epilogue = ((targetm.have_prologue () > > || targetm.have_epilogue ()) > > && reload_completed); > > > >so when !could_be_prologue_epilogue then passes shouldn't run into > >them if the comment is correct. But else even epilogue stmts could appear > >anywhere (like scheduled around)? So why's skipping those OK? > These insns don't exist until after reload has completed.  I think this > code is just trying to be more compile-time efficient and not look for > them when they're known to not exist. Yeah. Unfortunately it isn't trivial to see if this is a premature optimisation, or if this is needed for correctness instead. But it is stage 1 still :-) > >Are passes supposed to check whether they are dealing with pro/epilogue > >insns and not touch them? CCing people that might know. > Generally most passes can treat them as any other RTL. Yup, if the *logues are just RTL, that RTL follows just the normal semantics of RTL. This means that dead code can be deleted, etc. Well that is about the most interesting transform that can be done so late in the compilation pipeline :-) Segher