[dataflow]: PATCH COMMITTED to fix frame pointer use in dce.

Bernd Schmidt bernds_cb1@t-online.de
Mon May 21 17:13:00 GMT 2007


Richard Sandiford wrote:
>> The resolution was that the frame_pointer would be made an artificial
>> use after reload if FRAME_POINTER_NEEDED was true and that frame related
>> insns could be deleted if they had a REG_MAYBE_DEAD note attached. 
> 
> Sorry to open old wounds, but...
> 
>>     * dce.c (deletable_insn_p): Only allow frame-related insns to be
>>     deleted if there is a REG_MAYBE_DEAD note.
> 
> ...I'm surprised that we're still checking RTX_FRAME_RELATED_P at
> all here.  I know that's what you and Ian were talking about early
> on in the conversation, but I'd hoped that the "consider the frame
> pointer to be live if frame_pointer_needed" idea had superceded it.

Well, I appreciate that we're trying to reinvent the wheel with the
dataflow work, but it might sense to reuse some of the existing logic in
flow.c.  In particular,

      /* If we're trying to delete a prologue or epilogue instruction
         that isn't flagged as possibly being dead, something is wrong.
         But if we are keeping the stack pointer depressed, we might well
         be deleting insns that are used to compute the amount to update
         it by, so they are fine.  */
      if (reload_completed
          && !(TREE_CODE (TREE_TYPE (current_function_decl)) ==
FUNCTION_TYPE
                && (TYPE_RETURNS_STACK_DEPRESSED
                    (TREE_TYPE (current_function_decl))))
          && (((HAVE_epilogue || HAVE_prologue)
               && prologue_epilogue_contains (insn))
              || (HAVE_sibcall_epilogue
                  && sibcall_epilogue_contains (insn)))
          && find_reg_note (insn, REG_MAYBE_DEAD, NULL_RTX) == 0)
        fatal_insn ("Attempt to delete prologue/epilogue insn:", insn);

Why not keep the same logic, since it seems to work for us right now?
Here we're not testing RTX_FRAME_RELATED_P, but verifying that it's not
a prologue/epilogue insn we're trying to delete.

IMO it would make sense for dataflow to stay as close to existing RTL
semantics as possible, which means if something like the above doesn't
work there, it's a bug.

> As I said on IRC, I object to RTX_FRAME_RELATED_P being treated
> specially as a correctness measure because (a) it smacks too much
> of magic and (b) there's no guarantee that the (unknown) situations
> that need this magic don't occur for non-RTX_FRAME_RELATED_P insns too.

Agreed.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif



More information about the Gcc-patches mailing list