From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97385 invoked by alias); 10 Aug 2017 07:39:14 -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 97368 invoked by uid 89); 10 Aug 2017 07:39:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,KAM_MANYTO,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=activated, questioned, formation, UD:This X-HELO: mail-vk0-f68.google.com Received: from mail-vk0-f68.google.com (HELO mail-vk0-f68.google.com) (209.85.213.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Aug 2017 07:39:11 +0000 Received: by mail-vk0-f68.google.com with SMTP id i133so4721376vka.5 for ; Thu, 10 Aug 2017 00:39:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Fm9YX1VC6fl1mxTM4m1XeFbIeaRAEAzNnACGQYqwCQE=; b=gTr/QWzRWYGq63tKL75wbDrEgm4POGhy8fBSud2HTYSLpA1Gne9eSD11CCJEEPR1CF OevyxzCoM+Zb1xJxMlkokkXzC0xkN6Ovjdzg42v5dl9gHlWuTE3DVS8r8gUPAfr6+f3m BLwr5jVTW9LkwFcY1tHUS20DfQAEwuh09nqDfj9uZ+uuF9B4wBQJS3ScLY4bTHT4EhKj Y8AP7Uw8v4ZETj3vHgyVZAvcZNmzeU1PSpc4xvdxbz7Vjrv8onHt2Ci57EDJJyE/aguy 0VIqoLZeK0FidtPUtoB91Oig38TiO2SYpRh7Nr8B9mYQmFMLBnZAoukl9VX5xc3Exgq+ Poiw== X-Gm-Message-State: AHYfb5hCRZEiAm4Hk1iCs5FYgei+WcHXWtscXxiT2mkV/BsWz4Wuk15r fhp0lYVMhpqmvkVZlgRw9bN+ua0Buw== X-Received: by 10.31.108.16 with SMTP id h16mr6424275vkc.204.1502350749282; Thu, 10 Aug 2017 00:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.218 with HTTP; Thu, 10 Aug 2017 00:39:08 -0700 (PDT) In-Reply-To: <877eybx5jx.fsf@linaro.org> References: <87wp6e7ykz.fsf@linaro.org> <87shh27yho.fsf@linaro.org> <87d18589em.fsf@linaro.org> <874ltg4wb2.fsf@firstfloor.org> <20170809152622.GJ3044@two.firstfloor.org> <877eybx5jx.fsf@linaro.org> From: Uros Bizjak Date: Thu, 10 Aug 2017 07:51:00 -0000 Message-ID: Subject: Re: [PATCH] i386: Don't use frame pointer without stack access 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 Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-08/txt/msg00724.txt.bz2 On Thu, Aug 10, 2017 at 9:09 AM, Richard Sandiford wrote: > "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. As said earlier, I think we should proceed with the previous patch (that documents -fno-omit-frame-pointer limitations), It was demonstrated that the patch does not make current situation worse. -fkeep-frame-pointer is an orthogonal issue, and this option should guarantee frame formation in *all* situations.This means that the option should disable (partial) inlining, shrink-wrapping, etc. Actually, it would disable so much optimizations, that its usefullnes is questioned. OTOH, nobody ever complained about limited FP debugging "experience" when mentioned optimizations were activated. BTW: The option should be called -fforce-frame-pointer, but I really doubt about its usefullnes. Uros.