On Thu, Aug 10, 2017 at 12:39 AM, Uros Bizjak wrote:
> 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 i
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.
>
"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.
An
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
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 p
> 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 opti
On Wed, Aug 9, 2017 at 8:05 AM, Arjan van de Ven wrote:
> On 8/9/2017 8:04 AM, Andi Kleen wrote:
>>
>> 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.
This must be much m
On 8/9/2017 8:04 AM, Andi Kleen wrote:
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.
that function should also fix the current situation where the framepointer is
not useful
"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-point
On Wed, Aug 9, 2017 at 4:59 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 9 Aug 2017, H.J. Lu wrote:
>
>> > OK, but then both -f[no-]omit-frame-pointer do not have clearly defined
>> > semantics and thus shouldn't be exposed to the user?
>>
>> -f[no-]omit-frame-pointer apply to cases where a new stac
Hi,
On Wed, 9 Aug 2017, H.J. Lu wrote:
> > OK, but then both -f[no-]omit-frame-pointer do not have clearly defined
> > semantics and thus shouldn't be exposed to the user?
>
> -f[no-]omit-frame-pointer apply to cases where a new stack frame
> is needed. -fno-omit-frame-pointer allows you to un
On Wed, Aug 9, 2017 at 4:22 AM, Richard Biener
wrote:
> On August 9, 2017 9:53:05 AM GMT+02:00, Richard Sandiford
> wrote:
>>Richard Biener writes:
>>> On August 8, 2017 7:36:35 PM GMT+02:00, Richard Sandiford
>>> wrote:
Richard Sandiford writes:
> Richard Biener writes:
>> On Au
On August 9, 2017 9:53:05 AM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On August 8, 2017 7:36:35 PM GMT+02:00, Richard Sandiford
>> wrote:
>>>Richard Sandiford writes:
Richard Biener writes:
> On August 8, 2017 6:38:30 PM GMT+02:00, "H.J. Lu"
>>> wrote:
>>On
Richard Biener writes:
> On August 8, 2017 7:36:35 PM GMT+02:00, Richard Sandiford
> wrote:
>>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 va
On Tue, Aug 8, 2017 at 11:00 AM, Richard Biener
wrote:
> On August 8, 2017 7:36:35 PM GMT+02:00, Richard Sandiford
> wrote:
>>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 Sandi
On August 8, 2017 7:36:35 PM GMT+02:00, Richard Sandiford
wrote:
>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/20
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:2
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 L
On Tue, Aug 8, 2017 at 6:38 PM, 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 w
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 w
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
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
>
On Mon, Aug 7, 2017 at 3:48 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 7 Aug 2017, H.J. Lu wrote:
>
>> >> [hjl@gnu-tools-1 pr81736]$
>> >>
>> >> Does it mean clang is broken?
>> >
>> > In my book, yes.
>>
>> Does GCC do this for all targets or just x86?
>
> No idea. If so I'd say those other targe
Hi,
On Mon, 7 Aug 2017, Arjan van de Ven wrote:
> I'm not surprised to see one.
> I'm surprised to see a useless one.
>
> The "perf" benefit is real, and that's why I asked for one... but the reorder
> made it an expensive 3 instruction nop for all intents and purposes.
> If the pop was just bef
On Mon, Aug 7, 2017 at 9:19 AM, Arjan van de Ven wrote:
> On 8/7/2017 9:16 AM, Michael Matz wrote:
>>
>> Hi,
>>
>> On Mon, 7 Aug 2017, Arjan van de Ven wrote:
>>
>>> wanting a framepointer is very nice and desired...
>>> ... but if the optimizer/ins scheduler moves instructions outside of the
>>>
On 8/7/2017 9:16 AM, Michael Matz wrote:
Hi,
On Mon, 7 Aug 2017, Arjan van de Ven wrote:
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
Hi,
On Mon, 7 Aug 2017, Arjan van de Ven wrote:
> 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 tha
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 c
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-poin
On Mon, Aug 7, 2017 at 7:06 AM, Alexander Monakov wrote:
> On Mon, 7 Aug 2017, Michael Matz wrote:
>> > I am looking for a run-time test which breaks unwinder.
>>
>> I don't have one handy. Idea: make two threads, one endlessly looping in
>> the "frame-less" function, the other causing a signal t
On Mon, 7 Aug 2017, Michael Matz wrote:
> > I am looking for a run-time test which breaks unwinder.
>
> I don't have one handy. Idea: make two threads, one endlessly looping in
> the "frame-less" function, the other causing a signal to the first thread,
> and the signal handler checking that un
Hi,
On Mon, 7 Aug 2017, H.J. Lu wrote:
> >> [hjl@gnu-tools-1 pr81736]$
> >>
> >> Does it mean clang is broken?
> >
> > In my book, yes.
>
> Does GCC do this for all targets or just x86?
No idea. If so I'd say those other targets are broken as well (as long as
the concept of frame pointer make
On Mon, Aug 7, 2017 at 6:32 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 7 Aug 2017, H.J. Lu wrote:
>
>> >> This will break unwinders relying on frame pointers to exist on all
>> >> functions, for which projects conciously forced a frame pointer with this
>> >> option. I don't think we can simply ov
On Aug 07 2017, Michael Matz wrote:
> +/* { dg-final { scan-assembler "%\[re\]bp" } } */
Please use {} for regexps.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hi,
On Mon, 7 Aug 2017, H.J. Lu wrote:
> >> This will break unwinders relying on frame pointers to exist on all
> >> functions, for which projects conciously forced a frame pointer with this
> >> option. I don't think we can simply override user specified explicit
> >> wishes in this way, presum
On Mon, Aug 7, 2017 at 6:21 AM, Uros Bizjak wrote:
> On Mon, Aug 7, 2017 at 3:15 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 7 Aug 2017, Uros Bizjak wrote:
>>
>>> On Sun, Aug 6, 2017 at 9:40 PM, H.J. Lu wrote:
>>> > When there is no stack access, there is no need to use frame pointer
>>> > even
On Mon, Aug 7, 2017 at 3:15 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 7 Aug 2017, Uros Bizjak wrote:
>
>> On Sun, Aug 6, 2017 at 9:40 PM, H.J. Lu wrote:
>> > When there is no stack access, there is no need to use frame pointer
>> > even if -fno-omit-frame-pointer is used.
>> >
>> > Tested on i686
Hi,
On Mon, 7 Aug 2017, Uros Bizjak wrote:
> On Sun, Aug 6, 2017 at 9:40 PM, H.J. Lu wrote:
> > When there is no stack access, there is no need to use frame pointer
> > even if -fno-omit-frame-pointer is used.
> >
> > Tested on i686 and x86-64. OK for trunk?
>
> LGTM.
This will break unwinder
On Sun, Aug 6, 2017 at 9:40 PM, H.J. Lu wrote:
> When there is no stack access, there is no need to use frame pointer
> even if -fno-omit-frame-pointer is used.
>
> Tested on i686 and x86-64. OK for trunk?
>
> H.J.
> ---
> gcc/
>
> PR target/81736
> * config/i386/i386.c (ix86_fina
39 matches
Mail list logo
