[Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr

["zadeck at naturalbridge dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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