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 4666D39C503C for ; Thu, 4 Feb 2021 23:43:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4666D39C503C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@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 114Ng2dJ022735; Thu, 4 Feb 2021 17:42:02 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 114Ng1HI022734; Thu, 4 Feb 2021 17:42:01 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 4 Feb 2021 17:42:01 -0600 From: Segher Boessenkool To: Henri Cloetens Cc: gcc-help Subject: Re: Issue with frame pointer elimination Message-ID: <20210204234201.GG30983@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=-7.1 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 23:43:47 -0000 Hi! On Thu, Feb 04, 2021 at 11:54:09AM +0100, Henri Cloetens wrote: > I am working on a custom gcc.9.2.0 back end, and have an issue with > frame pointer elimination. It is a much better idea to use a more current GCC version, and it is easier to upgrade now than to upgrade later. Just a hint, do with it what you want :-) > - the result is OK till step '276 : ira (register allocation) > - the result is NG from step '277 onward (reload) Those numbers are useless to us: they depend on your configuration, and on the exact GCC version (it often changes within one major+minor+ patchlevel as well). The LRA pass (you do use LRA I hope?) sets up the hard frame pointer. If you look at that dump file you can see what happened and what went wrong (you'll probably need to look at the lra* files in the GCC source to figure out what happened exactly, what everything means). > What it did: It used R19 for the frame pointer. This register is > call-clobbered, but is not used for >   argument passing. Some way, it assumed to be free, but it is not. Is R19 the FRAME_POINTER_REGNUM or the HARD_FRAME_POINTER_REGNUM? You didn't show how you have anything of this set up, so it is hard to give more detailed advice. > So, the frame pointer is put in it, it is call-clobbered, and the result > is incorrect. > > If the compile flag -fomit-frame-pointer is used, the issue goes away. > > Has anybody any idea where to look ?. You need to save the register in your prologue code if frame_pointer_needed, etc. Segher