PING^1 [PATCH] DWARF: Relax SUPPORTS_STACK_ALIGNMENT with !crtl->stack_realign_tried

Jason Merrill jason@redhat.com
Thu Aug 30 17:22:00 GMT 2018


On Wed, Aug 29, 2018 at 7:31 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Aug 29, 2018 at 3:37 PM, Jason Merrill <jason@redhat.com> wrote:
>> On Wed, Aug 29, 2018 at 5:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Wed, Aug 29, 2018 at 2:17 PM, Jason Merrill <jason@redhat.com> wrote:
>>>> On Wed, Aug 29, 2018 at 3:38 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Wed, Aug 29, 2018 at 12:32 PM, Jason Merrill <jason@redhat.com> wrote:
>>>>>> On Wed, Aug 29, 2018 at 2:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>> On Wed, Aug 29, 2018 at 11:33 AM, Jason Merrill <jason@redhat.com> wrote:
>>>>>>>> On Wed, Aug 29, 2018 at 8:47 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>>> On Wed, Aug 8, 2018 at 6:32 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>>>> Assert for SUPPORTS_STACK_ALIGNMENT was added for dynamic stack
>>>>>>>>>> alignment.  At the time, arg_pointer_rtx would only be eliminated
>>>>>>>>>> by either hard_frame_pointer_rtx or stack_pointer_rtx only when
>>>>>>>>>> dynamic stack alignment is supported.  With
>>>>>>>>>>
>>>>>>>>>> commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
>>>>>>>>>> Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4>
>>>>>>>>>> Date:   Thu Aug 10 15:29:05 2017 +0000
>>>>>>>>>>
>>>>>>>>>>     i386: Don't use frame pointer without stack access
>>>>>>>>>>
>>>>>>>>>>     When there is no stack access, there is no need to use frame pointer
>>>>>>>>>>     even if -fno-omit-frame-pointer is used and caller's frame pointer is
>>>>>>>>>>     unchanged.
>>>>>>>>>>
>>>>>>>>>> this can happen when there is no dynamic stack alignment.  This patch
>>>>>>>>>> relaxes SUPPORTS_STACK_ALIGNMENT with !crtl->stack_realign_tried to
>>>>>>>>>> allow arg_pointer_rtx to be eliminated by either hard_frame_pointer_rtx
>>>>>>>>>> or stack_pointer_rtx when there is no dynamic stack alignment at all.
>>>>>>>>>>
>>>>>>>>>> gcc/
>>>>>>>>>>
>>>>>>>>>>         PR debug/86593
>>>>>>>>>>         * dwarf2out.c (based_loc_descr): Replace SUPPORTS_STACK_ALIGNMENT
>>>>>>>>>>         with (SUPPORTS_STACK_ALIGNMENT || !crtl->stack_realign_tried).
>>>>>>>>>>         (compute_frame_pointer_to_fb_displacement): Likewise.
>>>>>>>>>>
>>>>>>>>>> gcc/testsuite/
>>>>>>>>>>
>>>>>>>>>>         PR debug/86593
>>>>>>>>>>         * g++.dg/pr86593.C: New test.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PING:
>>>>>>>>>
>>>>>>>>> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00559.html
>>>>>>>>
>>>>>>>> It looks like crtl->stack_realign_tried is only ever set if
>>>>>>>> SUPPORTS_STACK_ALIGNMENT, so (SUPPORTS_STACK_ALIGNMENT ||
>>>>>>>> !crtl->stack_realign_tried) is always true.
>>>>>>>>
>>>>>>>> If you don't need to use the frame pointer, then frame_pointer_needed
>>>>>>>> should be false, so the assert should already allow elimination to the
>>>>>>>
>>>>>>> frame_pointer_needed is false:
>>>>>>>
>>>>>>> (gdb) p elim
>>>>>>> $1 = (rtx) 0x7fffeadd0390
>>>>>>> (gdb) call debug_rtx (elim)
>>>>>>> (reg/f:DI 6 bp)
>>>>>>> (gdb) call debug_rtx (reg)
>>>>>>> (reg/f:DI 16 argp)
>>>>>>> (gdb) p x_rtl.frame_pointer_needed
>>>>>>> $2 = false
>>>>>>> (gdb)
>>>>>>>
>>>>>>>> stack pointer.  Are we trying to eliminate to the hard frame pointer
>>>>>>>> even though we've decided we don't need it?  Why?
>>>>>>>
>>>>>>> In this case, we are trying to eliminate argp to the hard frame pointer.
>>>>>>
>>>>>> Right, but why are we trying to do that when frame_pointer_needed is false?
>>>>>
>>>>> With
>>>>>
>>>>> commit cd557ff63f388ad27c376d0a225e74d3594a6f9d
>>>>> Author: hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4>
>>>>> Date:   Thu Aug 10 15:29:05 2017 +0000
>>>>>
>>>>>     i386: Don't use frame pointer without stack access
>>>>>
>>>>>     When there is no stack access, there is no need to use frame pointer
>>>>>     even if -fno-omit-frame-pointer is used and caller's frame pointer is
>>>>>     unchanged.
>>>>>
>>>>> we may skip frame pointer when there is no stack access even if
>>>>> -fno-omit-frame-pointer is used.  Here argp is only referenced
>>>>> in debug info, not in the function body.  In this case, what else
>>>>> can argp be eliminated to in debug info?
>>>>
>>>> SP or CFA?
>>>>
>>>> If the function body doesn't set the hard frame pointer register, then
>>>> we can't rely on it having a useful value, so we shouldn't refer to it
>>>> in debug info.
>>>
>>> There are:
>>>
>>>                     (SUPPORTS_STACK_ALIGNMENT
>>>                        && (elim == hard_frame_pointer_rtx
>>>                            || elim == stack_pointer_rtx))
>>>
>>> When there is no stack realignment, SUPPORTS_STACK_ALIGNMENT
>>> isn't relevant.  Why can't elim be hard_frame_pointer_rtx?
>>
>> That change (by you, in r138335) looks to have been made to allow
>> eliminating to SP even when frame_pointer_needed, which is the
>> opposite of the current situation.  And which could be expressed as
>
> r138335 allowed arg_pointer_rtx to be eliminated by either FP or SP,
> but only when dynamic stack alignment is supported.  In this case,
> arg_pointer_rtx is eliminated by FP even when frame_pointer_needed
> is false and there is no dynamic stack alignment at all.
>
>> gcc_assert (elim == stack_pointer_rtx || (frame_pointer_needed && elim
>> == hard_frame_pointer_rtx));
>>
>> so as not to allow eliminating to an uninitialized FP.
>
> FP isn't uninitialized.  It is initialized the same way as in the case of
> SUPPORTS_STACK_ALIGNMENT is true.

How is that?  Why would it be initialized when frame_pointer_needed is
false?  What does it mean for frame_pointer_needed to be false, if
not, as in the documentation of -fomit-frame-pointer,

"This avoids the instructions to save, set up and restore the frame
pointer; on many targets it also makes an extra register available."

?

Jason



More information about the Gcc-patches mailing list