Hi, On Mon, 3 Sep 2018, H.J. Lu wrote:
> > So, what's the testcase testing then? Before the patch it doesn't ICE, > > after the patch it doesn't ICE. What should I look out for so I can see > > that what the testcase is producing without the patch is wrong? > > Before the patch, debug info is wrong since it uses hard frame pointer > which isn't set up for the function. You can do "readelf -w" on .o file to > verify the debug info. Yeah, that's what I thought as well, but it's correct: % ./gcc/cc1plus -quiet -O2 -g -fno-omit-frame-pointer -fvar-tracking x.cc % gcc -c x.s % readelf -wfi x.o ... <1><8a>: Abbrev Number: 9 (DW_TAG_subprogram) <8b> DW_AT_specification: <0x3a> <8f> DW_AT_decl_line : 6 <90> DW_AT_decl_column : 5 <91> DW_AT_object_pointer: <0xa7> <95> DW_AT_low_pc : 0x0 <9d> DW_AT_high_pc : 0x3 <a5> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <a7> DW_AT_GNU_all_call_sites: 1 ... <2><fe>: Abbrev Number: 11 (DW_TAG_formal_parameter) <ff> DW_AT_name : d <101> DW_AT_decl_file : 1 <102> DW_AT_decl_line : 6 <103> DW_AT_decl_column : 63 <104> DW_AT_type : <0x78> <108> DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8) ... DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_nop DW_CFA_nop ... So, argument 'd' is supposed to be at DW_AT_frame_base + 8, which is %rsp+8+8, aka %rsp+16, which is correct given that it's the eigth argument (including the implicit this parameter). So, can you actually show here what's broken before patch? > > You talking about this, right: > > > > /* We only use "frame base" when we're sure we're talking about the > > post-prologue local stack frame. We do this by *not* running > > register elimination until this point, and recognizing the special > > argument pointer and soft frame pointer rtx's. */ > > if (reg == arg_pointer_rtx || reg == frame_pointer_rtx) > > { > > rtx elim = (ira_use_lra_p > > ? lra_eliminate_regs (reg, VOIDmode, NULL_RTX) > > : eliminate_regs (reg, VOIDmode, NULL_RTX)); > > > > if (elim != reg) > > { > > ... > > > > So, why would eliminate_regs return hard_frame_pointer_rtx if no frame > > pointer is desired? > > Frame pointer was skipped at the last minute in > x86_finalize_stack_frame_flags. But eliminate_regs uses the info which > was computed when frame pointer was available. Let's assume something needs fixing (though I can't reproduce what right now) then I think changing frame_pointer_needed somehow needs to affect calls to {lra_,}eliminate_regs that come afterwards (by e.g. recalculating its info). Everything else is just asking for hacks upon hacks. Ciao, Michael.