From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93488 invoked by alias); 10 Aug 2017 07:17:03 -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 11479 invoked by uid 89); 10 Aug 2017 07:14:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 07:09:28 +0000 Received: by mail-wm0-f44.google.com with SMTP id i66so14365758wmg.0 for ; Thu, 10 Aug 2017 00:09:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=UY0w2wT85rTMGYBWsUWErw5gUdA+R4+finyndcW15OQ=; b=bc/wvEhNozpSoU9VU4cqvTF/WKGwOt2OlWf2UB8ZLIr+tyVB5ex5Eo+mMKslTHROvt bUcvA5kfAL1x3A54ZnGt8OacTCS/K2NycYNWHsOQGZ/QUdluUuuFuxGG6dZ17qT+gH2g GQBNmKdpXQSfxQLIkYSPX9hW5YbBhQmxNuT5tK9VBgWTFx/N5BeKxvyl8ER6s+aOxqz3 02nbqjU52Nf5iNUCEf+8R+BeP3t+sz+z+OXvJK39SQNe4DPK+cikGDYP5iSugSb8iMgl Jw2GOYAuxcV8NiuV/5GVjlyau3P94nMPcQiHZWFjbDtVm0oK+f4kO9qYpMtZQFyV57SM KFLw== X-Gm-Message-State: AHYfb5hmtJXv3qGaZSL+3cLPCd/fwAL+O4NRrQofORO+lbcwDHRKGsC8 wdDwHjCRecc/jH4P X-Received: by 10.28.169.82 with SMTP id s79mr6524633wme.123.1502348965450; Thu, 10 Aug 2017 00:09:25 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id f9sm4341479wmf.18.2017.08.10.00.09.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Aug 2017 00:09:24 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" ,Andi Kleen , Arjan van de Ven , Michael Matz , Richard Biener , GCC Patches , Jakub Jelinek , Alexander Monakov , Uros Bizjak , richard.sandiford@linaro.org Cc: Andi Kleen , Arjan van de Ven , Michael Matz , Richard Biener , GCC Patches , Jakub Jelinek , Alexander Monakov , Uros Bizjak Subject: Re: [PATCH] i386: Don't use frame pointer without stack access References: <87wp6e7ykz.fsf@linaro.org> <87shh27yho.fsf@linaro.org> <87d18589em.fsf@linaro.org> <874ltg4wb2.fsf@firstfloor.org> <20170809152622.GJ3044@two.firstfloor.org> Date: Thu, 10 Aug 2017 07:19:00 -0000 In-Reply-To: (H. J. Lu's message of "Wed, 9 Aug 2017 11:18:16 -0700") Message-ID: <877eybx5jx.fsf@linaro.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/msg00719.txt.bz2 "H.J. Lu" writes: > On Wed, Aug 9, 2017 at 10:28 AM, H.J. Lu wrote: >> On Wed, Aug 9, 2017 at 8:26 AM, Andi Kleen wrote: >>>> This must be much more specific. How does it impact: >>>> >>>> 1. LTO >>>> 2. Function inlining. >>>> 3. Partial function inlining. >>>> 4. Shrink-wrapping. >>>> >>>> Any of them can impact function stack frame. >>> >>> It doesn't. It's just to get back to the previous state. >>> >>> Also these others already have explicit options to disable them. >>> >> >> How about >> >> item -fkeep-frame-pointer >> @opindex fkeep-frame-pointer >> Keep the frame pointer in a register for functions. This option always >> forces a new stack frame for all functions regardless of whether >> @option{-fomit-frame-pointer} is enabled or not. Disabled by default. >> > > Here is the updated patch with -fkeep-frame-pointer. It sounds like there's still some disagreement about what this option should mean; Andi's and Arjan's replies didn't seem to be asking for the same thing. I think as implemented the patch just retains the GCC 7 x86 behaviour of -fno-omit-frame-pointer, i.e. forces a frame to be created *somewhere* between the start and end addresses of the function, but makes no guarantee where. It could be a bundle of three instructions somewhere in the middle of a basic block, and the code might not be executed for all paths through the function (e.g. it might only be executed on error paths). I think even if we think that's useful, it should be documented clearly. Otherwise people might assume that a function f is guaranteed to set up a frame every time it's called. Thanks, Richard From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29918 invoked by alias); 10 Aug 2017 07:21:56 -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 29776 invoked by uid 89); 10 Aug 2017 07:21:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=unavailable version=3.3.2 spammy= X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 07:21:52 +0000 Received: by mail-wm0-f53.google.com with SMTP id m85so12648042wma.0 for ; Thu, 10 Aug 2017 00:21:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=UY0w2wT85rTMGYBWsUWErw5gUdA+R4+finyndcW15OQ=; b=PgvnCpExHjZ2xIj5OL/UfTlEA5YQq16SRVwj1L5383tcajgw6UMrdP1zQ4cw3R0180 iYBzVh7g9VFc0yq8W5uYk8Tv18/7/WzOt5S/66H4c/NifC64Ul5iswz3e9if8neSzEd1 ugfmB0BQ/xO9cNltkugMHFG/vwsiQFp0eyEkGU73r4I44OXKEnVVvpZQ5/ayApneXdg2 IeAgx9KZntS8nLK2s4JSrlLPhWxguKax9B+Ne7x8QVTHJuHXoaXwk0dYf/C4sN4SN0ku odSGitb2Cj2vMW9FTwHuEvzoZo+NiIwabd93IhF/QO+9ph7YVV1J670eOAGujS5VNmYZ Rxdw== X-Gm-Message-State: AHYfb5h/Xbw+rMNK4PetXqNjOhGfNaJ4g36wM7f6PBgew6m0VPlOHbQS mF+jowxGmXzBEteC X-Received: by 10.28.169.82 with SMTP id s79mr6524633wme.123.1502348965450; Thu, 10 Aug 2017 00:09:25 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id f9sm4341479wmf.18.2017.08.10.00.09.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Aug 2017 00:09:24 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" ,Andi Kleen , Arjan van de Ven , Michael Matz , Richard Biener , GCC Patches , Jakub Jelinek , Alexander Monakov , Uros Bizjak , richard.sandiford@linaro.org Cc: Andi Kleen , Arjan van de Ven , Michael Matz , Richard Biener , GCC Patches , Jakub Jelinek , Alexander Monakov , Uros Bizjak Subject: Re: [PATCH] i386: Don't use frame pointer without stack access References: <87wp6e7ykz.fsf@linaro.org> <87shh27yho.fsf@linaro.org> <87d18589em.fsf@linaro.org> <874ltg4wb2.fsf@firstfloor.org> <20170809152622.GJ3044@two.firstfloor.org> Date: Thu, 10 Aug 2017 07:40:00 -0000 In-Reply-To: (H. J. Lu's message of "Wed, 9 Aug 2017 11:18:16 -0700") Message-ID: <877eybx5jx.fsf@linaro.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/msg00722.txt.bz2 Message-ID: <20170810074000.slW9eWJc8L4I-Oaabhnfw1rkvaBh7wEN5yuZLgDR8s4@z> "H.J. Lu" writes: > On Wed, Aug 9, 2017 at 10:28 AM, H.J. Lu wrote: >> On Wed, Aug 9, 2017 at 8:26 AM, Andi Kleen wrote: >>>> This must be much more specific. How does it impact: >>>> >>>> 1. LTO >>>> 2. Function inlining. >>>> 3. Partial function inlining. >>>> 4. Shrink-wrapping. >>>> >>>> Any of them can impact function stack frame. >>> >>> It doesn't. It's just to get back to the previous state. >>> >>> Also these others already have explicit options to disable them. >>> >> >> How about >> >> item -fkeep-frame-pointer >> @opindex fkeep-frame-pointer >> Keep the frame pointer in a register for functions. This option always >> forces a new stack frame for all functions regardless of whether >> @option{-fomit-frame-pointer} is enabled or not. Disabled by default. >> > > Here is the updated patch with -fkeep-frame-pointer. It sounds like there's still some disagreement about what this option should mean; Andi's and Arjan's replies didn't seem to be asking for the same thing. I think as implemented the patch just retains the GCC 7 x86 behaviour of -fno-omit-frame-pointer, i.e. forces a frame to be created *somewhere* between the start and end addresses of the function, but makes no guarantee where. It could be a bundle of three instructions somewhere in the middle of a basic block, and the code might not be executed for all paths through the function (e.g. it might only be executed on error paths). I think even if we think that's useful, it should be documented clearly. Otherwise people might assume that a function f is guaranteed to set up a frame every time it's called. Thanks, Richard