From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104980 invoked by alias); 8 Aug 2017 17:36:42 -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 104945 invoked by uid 89); 8 Aug 2017 17:36:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f181.google.com Received: from mail-wr0-f181.google.com (HELO mail-wr0-f181.google.com) (209.85.128.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Aug 2017 17:36:39 +0000 Received: by mail-wr0-f181.google.com with SMTP id y43so15453252wrd.3 for ; Tue, 08 Aug 2017 10:36:39 -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=bhkEh3pusYFa6fsrndhvH6kTGHpCC/+z9YeJ6Uu9vV4=; b=ZQn524dhoIyfauJX4LZXv/GgSreYFgot+nri9QE5IOHeETVbuSfRm6405jYL0U/WHx keHlm0cW73jvVEgM8Po+o+tvMp0gpbZFM/m0I05VnWUUVq3c14UK13ASs/xVQYVmSrGn BiewpmixUoNw4d+ZRSqRkuj3Dv4Y179K5AygEW7RIxuVp7K9oVrTU37+TC/gCU4H/4lF vctUGFcNf+nJf3lJIlfwQ1JxEl5ekC9HQzX6YrptRQc9S5CZvPO1CqnCEhBtbcv4VDqw klZ9TUo2nr40bhfB8bCaK3uSI69p0dDAVpi6iiahm0udWbsjxcqC+lKQV4F7M+z1NoZe EZTQ== X-Gm-Message-State: AHYfb5jgRJqZXETvAM9Xtb/prLZiaM0HeXb72xFtuL+j1Zo4StKUEoGr gulzNiNzPS8wgQEU X-Received: by 10.223.162.207 with SMTP id t15mr4120155wra.151.1502213797284; Tue, 08 Aug 2017 10:36:37 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id p68sm14214390wmf.0.2017.08.08.10.36.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 Aug 2017 10:36:36 -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> <87wp6e7ykz.fsf@linaro.org> Date: Tue, 08 Aug 2017 17:36:00 -0000 In-Reply-To: <87wp6e7ykz.fsf@linaro.org> (Richard Sandiford's message of "Tue, 08 Aug 2017 18:34:36 +0100") Message-ID: <87shh27yho.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/msg00613.txt.bz2 Richard Sandiford writes: > 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. er, you know what I mean :-) It doesn't have any effect on -fshrink-wrapping or the textual-style prologues and epilogues.