------- Comment #20 from zadeck at naturalbridge dot com 2007-10-06 21:20 ------- Subject: Re: [4.3 regression]: wrong code with -fforce-addr
ubizjak at gmail dot com wrote: > ------- Comment #19 from ubizjak at gmail dot com 2007-10-06 19:58 ------- > In dse.c, scan_insn(), we have: > > if ((GET_CODE (PATTERN (insn)) == CLOBBER) > || volatile_refs_p (PATTERN (insn)) > || (flag_non_call_exceptions && may_trap_p (PATTERN (insn))) > || (RTX_FRAME_RELATED_P (insn)) > || find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX)) > insn_info->cannot_delete = true; > > And since the docs say that: > > `RTX_FRAME_RELATED_P (X)' > Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or > `set' which is part of a function prologue and sets the stack > pointer, sets the frame pointer, or saves a register. This flag > should also be set on an instruction that sets up a temporary > register to use in place of the frame pointer. Stored in the > `frame_related' field and printed as `/f'. > > I wonder if the insn that stores to (or uses(?)) this temporary register (in > place of the frame pointer) should also be marked as frame related insn? > > So, all the insns in the sequence of > > set tmpreg, FP + const > ... > store (tmpreg) > > should be marked as frame related insns. > > > i was not referring to the frame_related flag, though i guess it could be taken over for this purpose. Note that the frame_related flag is for use by the prologue and this is not. This is just a register that happens to point into the frame, which i think is only ever created if you say -fforce-addr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
