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 gcc_assert (elim == stack_pointer_rtx || (frame_pointer_needed && elim == hard_frame_pointer_rtx)); so as not to allow eliminating to an uninitialized FP. Jason
