This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: try_split lossage


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]