try_split lossage
John Wehle
john@feith.com
Wed Aug 4 00:49:00 GMT 1999
> In message <199906161751.NAA13265@jwlab.FEITH.COM>you write:
> > An insn may have various characteristics (such as CONST_CALL_P,
> > INSN_ANNULLED_BRANCH_P, INSN_FROM_TARGET_P, RTX_FRAME_RELATED_P)
> > which affect code generation. try_split attempts to replace the
> > insn with other insn(s). What isn't clear to me is how the new
> > insn(s) inherit the characteristics of the insn which is being
> > replaced.
> >
> > Should try_split either abort or avoid splitting insns which
> > have any of these characteristics?
> Well, losing a CONST_CALL_P or RTX_FRAME_RELATED_P shouldn't cause any serious
> problems.
The following is from dwarf2out_frame_debug:
if (! RTX_FRAME_RELATED_P (insn))
{
dwarf2out_stack_adjust (insn);
return;
}
dwarf2out_stack_adjust has the comment:
/* Check INSN to see if it looks like a push or a stack adjustment, and
make a note of it if it does. EH uses this information to find out how
much extra space it needs to pop off the stack. */
There seems to be the potential to break EH if RTX_FRAME_RELATED_P is
incorrect, however I'm somewhat naive when it comes to EH or dwarf2.
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------
More information about the Gcc
mailing list