Bad code from egcs-1.1b

Mark Mitchell mark@markmitchell.com
Mon Oct 26 07:47:00 GMT 1998


>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

>>>>> Jeffrey A Law <law@cygnus.com> writes:

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

    Jason> The jump code refuses because duplicating the notes is
    Jason> invalid.  Moving them isn't, so long as the order is
    Jason> preserved, and it seems to me that the order would only be
    Jason> broken iff the test contains block notes and the loop body
    Jason> contains block notes.  That seems quite testable.

Yes, but not good enough to allow good optimization.  (Not that I'm
defending the current behavior, which, incidentally, is probably my
fault.)  The problem is that in C++ function-inlining completely
messes us the optimizations involving moving the exit test since we
get BLOCKs from the inlined function.  Even if these blocks are tiny
(like if the inline is just an accessor) we can't move the test.
Then, we don't recognize the loop as a loop since we didn't move the
test, and didn't create VTOP notes, and then no loop optimization is
done. 

    Jason> Another possibility would be to associate the fixup with
    Jason> something other than a block; perhaps a code_label?

Yes, this would be better.  I suspect the confusion with your test
case is occurring because the NOTE_BLOCK_{BEGIN,END} pair is *not*
moved by expand_end_loop; only the code inside it is moved.  This
hackery is done to avoid confusing the debug-generation code which
relies on BLOCK notes remaining in their original order forever. 

That's the real problem, and has other unfortunate impacts as well.
If we fix that, then I think your problem would go away, since the
BLOCK notes would get moved with the code in the BLOCK.  Do you feel
like trying this?  I could also take a go at it later in the week if
you can't.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com



More information about the Gcc-bugs mailing list