On Wed, Aug 29, 2018 at 7:31 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Wed, Aug 29, 2018 at 3:37 PM, Jason Merrill <ja...@redhat.com> wrote: >> On Wed, Aug 29, 2018 at 5:43 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Wed, Aug 29, 2018 at 2:17 PM, Jason Merrill <ja...@redhat.com> wrote: >>>> On Wed, Aug 29, 2018 at 3:38 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>> On Wed, Aug 29, 2018 at 12:32 PM, Jason Merrill <ja...@redhat.com> wrote: >>>>>> On Wed, Aug 29, 2018 at 2:59 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>>>> On Wed, Aug 29, 2018 at 11:33 AM, Jason Merrill <ja...@redhat.com> >>>>>>> wrote: >>>>>>>> On Wed, Aug 29, 2018 at 8:47 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>>>>>>> On Wed, Aug 8, 2018 at 6:32 AM, H.J. Lu <hjl.to...@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
