Re: Improvement to loop optimization in presence of inlining

[Jeffrey A Law <law at cygnus dot com>]

  In message <199806292140.OAA29989@smtp.earthlink.net>you write:
  >   This patch, I have just realized, will screw up debugging information.
  >   I shall have to think about how to fix that.  For now, I'd still
  >   appreciate comments on the patch, but I hereby retract it from the
  >   submission queue. :-(
A general note -- we often allow more aggressive opts at -O2 that
might make debugging hard (there's a fine line between hard and 
impossible :-)

  > 
  > OK, here's an improved version.  This version should not through 
  > debugging information into total disarray.  Jeff, OK?
  > 
  > Sun Jun 28 18:25:20 1998  Mark Mitchell  <mark@markmitchell.com>
  > 
  > 	* jump.c (duplicate_loop_exit_test): Don't refuse to copy a
  > 	section of code just because it contains
  > 	NOTE_INSN_BLOCK_{BEG,END}.
  > 	* stmt.c (expand_end_loop): Likewise.  Also, don't refuse to 
  > 	move CALL_INSNs or CODE_LABELs.  When moving code, don't move
  > 	NOTE_INSN_BLOCK_{BEG,END}.
These comments apply to the changes in both files.

So this leaves the BLOCK_BEG/BLOCK_END notes in-place since they're
not copied later in duplicate_loop_exit_test.  Doesn't this scrogg
debugging too?  If so, we might want to only allow them in the stream
if optimize > 1.

The other question is could the loop rotation create a situation where
the compiler would later delete those notes?  And if so, is that safe
considering the relationship that has to be kept between the rtl and
tree structures for block scope info?

You may also need to avoid some of this code restructuring in the
presense of EH notes.  I believe it's a bug that this code doesn't
respect EH notes at the current time.  In fact, I think there was
a bug report recently about some of the code in jump.c not honoring
EH notes, but I haven't looked at it in any detail yet.

jeff