From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105259 invoked by alias); 9 Aug 2017 15:04:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 101209 invoked by uid 89); 9 Aug 2017 15:04:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_FAIL autolearn=no version=3.3.2 spammy= X-HELO: mga05.intel.com Received: from mga05.intel.com (HELO mga05.intel.com) (192.55.52.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Aug 2017 15:04:19 +0000 Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 09 Aug 2017 08:04:17 -0700 X-ExtLoop1: 1 Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.35]) by fmsmga004.fm.intel.com with ESMTP; 09 Aug 2017 08:04:17 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 718F230053E; Wed, 9 Aug 2017 08:04:17 -0700 (PDT) From: Andi Kleen To: "H.J. Lu" Cc: Michael Matz , Richard Biener , Richard Sandiford , GCC Patches , Arjan van de Ven , Jakub Jelinek , Alexander Monakov , Uros Bizjak Subject: Re: [PATCH] i386: Don't use frame pointer without stack access References: <20170806194037.GA25845@gmail.com> <20170807154311.GN2123@tucnak> <9c734d2b-7ba2-057b-7505-a7b300cde472@linux.intel.com> <878tivdtz9.fsf@linaro.org> <87wp6e7ykz.fsf@linaro.org> <87shh27yho.fsf@linaro.org> <87d18589em.fsf@linaro.org> Date: Wed, 09 Aug 2017 15:04:00 -0000 In-Reply-To: (H. J. Lu's message of "Wed, 9 Aug 2017 05:26:58 -0700") Message-ID: <874ltg4wb2.fsf@firstfloor.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-08/txt/msg00668.txt.bz2 "H.J. Lu" writes: > > Like this? > > Note that @option{-fno-omit-frame-pointer} doesn't force a new stack > frame for all functions if it isn't otherwise needed, and hence doesn't > guarantee a new frame pointer for all functions. > > Here is the updated patch with a note for -fno-omit-frame-pointer. > > OK for trunk? I suspect there will be still some unwinder or code patching setups which rely on frame pointer everywhere become broken. But doing the optimization for -fno-omit-frame-pointer by default seems reasonable. I would add a new option -fforce-frame-pointer that gives the old -fno-omit-frame-pointer back, so that users relying on frame pointers everywhere have a workaround. -Andi