Re: Bad code from egcs-1.1b

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

  In message <u9iuh8aq1q.fsf@yorick.cygnus.com>you write:
  > I tracked this down.  The problem is that 
  > 
  > 1) expand_fixup emits BLOCK_{BEGIN,END} notes to indicate where a cleanup
  >    should go, and then
  > 2) expand_end_loop moves them to the beginning of the loop, and then
  > 3) fixup_gotos expands the code for the cleanups into the wrong place.
  > 
  > Jeff, thoughts?
I wonder how much faster you found this than I did....  I just got into the
expand_end_loop code, but hadn't figured out why it was causing us to lose.
I hate optimizations that muck with the rtl before the first rtl dump!
[ The only way I find it was by noticing that the behavior of expand_end_loop
  differed for -O1 and -O2 :( ]

Funny that we both selected tonight to look at the problem :-)

jump.c::duplicate_loop_exit_test simply refuses to roll loops in this manner
if it finds a BLOCK_{BEGIN,END} note.    We could do the same.  I don't see
many alternatives.

Is there any way to distinguish between a random BLOCK_{BEG,END} and one
used for placement of cleanups?  If we could, then we could avoid totally
disabling this optimization.

jeff