From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99642 invoked by alias); 8 Aug 2017 17:34:45 -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 99629 invoked by uid 89); 8 Aug 2017 17:34:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Aug 2017 17:34:42 +0000 Received: by mail-wr0-f176.google.com with SMTP id k71so15520321wrc.2 for ; Tue, 08 Aug 2017 10:34:42 -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=OcocgwozBNxOLKoMR+megJHAzNeDkQWJ4Xpf06xvruw=; b=IjuAqodRSGHLUbjXl8YwkrZA9tDJ1QAWNGIX1x1dhdhdbhb4dBchDYc9cbSOye0bws glbSbShOwVv3vMdSgUg2kciqe5hJT0iMqoOoJ0P+y86wsuXAoBnT1RgVkEtR0rKVPNE/ rmaFEbAOXvOIeLUDXGDPM+OPHOMSOOFnYFsAT635CDkCBj+8YmKsjlmMlFZ+fV5rIqDr a/wOYsb5QZNxu3ioTf00bchQF9OTr1qQC1Nf4qYqUd+8TsDEaUM/bW2Tgcso3h4v2gQD ppub3pyE5//QistwWnswNT2BWaxhJ9jYaFlsGqUxRLlVHaIYwcd8O8/ee1ftqkLod4oX ewMA== X-Gm-Message-State: AHYfb5iFCpiXd78l0HTiFCf/+H+yoAvb24LQhuNsrK3RbkEec91WR3jj tqFdI/FWEwVPpRMR X-Received: by 10.223.163.158 with SMTP id l30mr4024279wrb.203.1502213680696; Tue, 08 Aug 2017 10:34:40 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id c34sm2913775wra.80.2017.08.08.10.34.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 Aug 2017 10:34:37 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,gcc-patches@gcc.gnu.org, "H.J. Lu" , Arjan van de Ven , Jakub Jelinek , Alexander Monakov , Michael Matz , Uros Bizjak , richard.sandiford@linaro.org Cc: gcc-patches@gcc.gnu.org, "H.J. Lu" , Arjan van de Ven , Jakub Jelinek , Alexander Monakov , Michael Matz , 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> Date: Tue, 08 Aug 2017 17:34:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 08 Aug 2017 19:00:57 +0200") Message-ID: <87wp6e7ykz.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/msg00612.txt.bz2 Richard Biener writes: > On August 8, 2017 6:38:30 PM GMT+02:00, "H.J. Lu" wrote: >>On Mon, Aug 7, 2017 at 1:05 PM, Richard Sandiford >> wrote: >>> Arjan van de Ven writes: >>>> On 8/7/2017 8:43 AM, Jakub Jelinek wrote: >>>>> On Mon, Aug 07, 2017 at 08:39:24AM -0700, H.J. Lu wrote: >>>>>> When Linux/x86-64 kernel is compiled with -fno-omit-frame-pointer. >>>>>> this optimization removes more than 730 >>>>>> >>>>>> pushq %rbp >>>>>> movq %rsp, %rbp >>>>>> popq %rbp >>>>> >>>>> If you don't want the frame pointer, why are you compiling with >>>>> -fno-omit-frame-pointer? Are you going to add >>>>> -fforce-no-omit-frame-pointer or something similar so that people >>can >>>>> actually get what they are asking for? This doesn't really make >>sense. >>>>> It is perfectly fine to omit frame pointer by default, when it >>isn't >>>>> required for something, but if the user asks for it, we shouldn't >>ignore his >>>>> request. >>>>> >>>> >>>> >>>> wanting a framepointer is very nice and desired... ... but if the >>>> optimizer/ins scheduler moves instructions outside of the frame'd >>>> portion, (it does it for cases like below as well), the value is >>>> already negative for these functions that don't have stack use. >>>> >>>> : >>>> mov all_schedules@@Base-0x38460,%rax >>>> push %rbp >>>> mov %rsp,%rbp >>>> pop %rbp >>>> cmpq $0x0,(%rax) >>>> setne %al >>>> movzbl %al,%eax >>>> retq >>> >>> Yeah, and it could be even weirder for big single-block functions. >>> I think GCC has been doing this kind of scheduling of prologue and >>> epilogue instructions for a while, so there hasn*t really been a >>> guarantee which parts of the function will have a new FP and which >>> will still have the old one. >>> >>> Also, with an arbitrarily-picked host compiler (GCC 6.3.1), >>shrink-wrapping >>> kicks in when the following is compiled with -O3 >>-fno-omit-frame-pointer: >>> >>> void f (int *); >>> void >>> g (int *x) >>> { >>> for (int i = 0; i < 1000; ++i) >>> x[i] += 1; >>> if (x[0]) >>> { >>> int temp; >>> f (&temp); >>> } >>> } >>> >>> so only the block with the call to f sets up FP. The relatively >>> long-running loop runs with the caller's FP. >>> >>> I hope we can go for a target-independent position that what HJ*s >>> patch does is OK... >>> >> >>In light of this, I am resubmitting my patch. I added 3 more >>testcases >>and also handle: >> >>typedef int v8si __attribute__ ((vector_size (32))); >> >>void >>foo (v8si *out_start, v8si *out_end, v8si *regions) >>{ >> v8si base = regions[3]; >> *out_start = base; >> *out_end = base; >>} >> >>OK for trunk? > > The invoker specified -fno-omit-frame-pointer, why did you eliminate it? > I'd argue it's OK when neither -f nor -fno- is explicitly specified > irrespective of the default in case we document the change but an > explicit -fno- is pretty clear. I don't buy that we're ignoring the user. -fomit-frame-pointer says that, when you're creating a frame, it's OK not to set up the frame pointer. Forcing it off means that if you create a frame, you need to set up the frame pointer too. But it doesn't say anything about whether the frame itself is needed. I.e. it's -fno-omit-frame*-pointer* rather than -fno-omit-frame. It seems like the responses have been treating it more like a combination of: -fno-shrink-wrapping -fno-omit-frame-pointer the equivalent of the old textual prologues and epilogues but the positive option -fomit-frame-pointer doesn't have any effect on the last two. Thanks, Richard