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] |
Hi Jeff, >>> I may be missing something, but isn't it the transition to an FP >>> relative address rather than a SP relative address that's the problem >>> here? >> >> Yes, I believe so. >> >>> Where does that happen? I think that it happens in dwarf2out.c:based_loc_descr() which detects the use of the frame pointer and works out that it is going to be eliminated to the stack pointer: /* 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) ..... The problem, I believe, is that based_loc_descr() is only called from mem_loc_descriptor when the mode of the rtl concerned is an MODE_INT. For example: case REG: if (GET_MODE_CLASS (mode) != MODE_INT [...] else if (REGNO (rtl) < FIRST_PSEUDO_REGISTER) mem_loc_result = based_loc_descr (rtl, 0, VAR_INIT_STATUS_INITIALIZED); or, (this is another one that I found whilst investigating this problem further): case PLUS: plus: if (is_based_loc (rtl) && (GET_MODE_SIZE (mode) <= DWARF2_ADDR_SIZE || XEXP (rtl, 0) == arg_pointer_rtx || XEXP (rtl, 0) == frame_pointer_rtx) && GET_MODE_CLASS (mode) == MODE_INT) mem_loc_result = based_loc_descr (XEXP (rtl, 0), INTVAL (XEXP (rtl, 1)), VAR_INIT_STATUS_INITIALIZED); else There are quite a few places in mem_loc_descriptor where the code checks for the mode being in the MODE_INT class. I am not exactly sure why. I think that it might be that the programmer thought that any expression that does not involve integer based arithmetic cannot be expressed in DWARF CFA notation and so would have to be handled specially. If I am correct, then it seems to me that the proper fix would be to use SCALAR_INT_MODE_P instead. I tried out the extended patch (attached) and it gave even better GDB results for the MSP430 and still no regressions (GCC or GDB) for MSP430 or x86_64. Is this enough justification ? Cheers Nick
Attachment:
dwarf2out.c.patch.2
Description: Unix manual page
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |