This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: Replace hard frame pointer with stack pointer - UNITS_PER_WORD


On Mon, Sep 3, 2018 at 7:32 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Sun, 2 Sep 2018, H.J. Lu wrote:
>
>> Here is the patch to replace hard frame pointer with stack pointer
>> - UNITS_PER_WORD in x86 backend.
>>
>> OK for trunk?
>>
>> +// { dg-options "-O -g -fno-omit-frame-pointer -fvar-tracking" }
>> +
>> +struct Foo
>> +{
>> +  int bar(int a, int b, int c, int i1, int i2, int i3, int d);
>> +};
>> +
>> +int Foo::bar(int a, int b, int c, int i1, int i2, int i3, int d)
>> +{
>> +  return 0;
>> +}
>> diff --git a/gcc/testsuite/g++.dg/pr86593-2.C b/gcc/testsuite/g++.dg/pr86593-2.C
>> +// { dg-options "-O -g -fno-omit-frame-pointer -fno-var-tracking" }
>> +
>> +struct Foo
>> +{
>> +  int bar(int a, int b, int c, int i1, int i2, int i3, int d);
>> +};
>> +
>> +int Foo::bar(int a, int b, int c, int i1, int i2, int i3, int d)
>> +{
>> +  return 0;
>> +}
>
> I can't seem to reproduce any ICEs with trunk on the above two testcases
> (configured for x86_64-linux):
>
> % ./gcc/cc1plus -quiet -O -g -fno-omit-frame-pointer -fno-var-tracking x.cc
> % ./gcc/cc1plus -quiet -O -g -fno-omit-frame-pointer -fvar-tracking x.cc

It is because of

         gcc_assert ((SUPPORTS_STACK_ALIGNMENT
                       && (elim == hard_frame_pointer_rtx  <<<<<<<<<<<<

It allows hard frame pointer even if frame pointer isn't available.

                           || elim == stack_pointer_rtx))
                      || elim == (frame_pointer_needed
                                  ? hard_frame_pointer_rtx
                                  : stack_pointer_rtx));

> I get the feeling this needs to be fixed somewhere else, namely
> eliminate_regs.  Basically if the frame pointer isn't needed, then why is
> hard_frame_pointer_rtx even somewhere in the final RTL?  The elimination
> you do explicitely in your new routines should have been done as part of
> general register elimination.  Why isn't it?

hard frame pointer isn't referenced directly in the final RTL.  It is arg
pointer in debug info, which is eliminated by hard frame pointer in
based_loc_desc.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]