This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: try_split lossage
- To: law at cygnus dot com
- Subject: Re: try_split lossage
- From: John Wehle <john at feith dot com>
- Date: Wed, 4 Aug 1999 03:49:23 -0400 (EDT)
- cc: egcs at egcs dot cygnus dot com
> 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 | |
-------------------------------------------------------------------------