Re: Help w/ CFG/loop optimization problem?

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

 In message <Pine.LNX.4.33.0209111141390.2774-100000@www.eyesopen.com>, Roger 
Sayle writes:

 >I agree with you completely.  Long branch support is dealt with *much*
 >later in the compiler.  However, the current code intentionally produces
 >strange RTL.  The comment in "expand_loop_exit_if_false" in stmt.c
 >currently reads:
 >
 >  /* In order to handle fixups, we actually create a conditional jump
 >     around an unconditional branch to exit the loop.  If fixups are
 >     necessary, they go before the unconditional branch.  */
 >
 >  rtx label = gen_label_rtx ();
 >  do_jump (cond, NULL_RTX, label);
 >  last_insn = get_last_insn ();
 >  if (GET_CODE (last_insn) == CODE_LABEL)
 >    whichloop->data.loop.alt_end_label = last_insn;
 >  expand_goto_internal (NULL_TREE, whichloop->data.loop.end_label,
 >                        NULL_RTX);
 >  emit_label (label);
I suspect "fixups" in this case is actually referring to the need for
a location where we can place destructors and possibly other code which
we need to execute as we leave the scope defined by the loop.

We can't put them at the target of the jump as we can't be sure 
what other jumps might reach that target.

We could possibly emit the straightforward code and put the fixups
after the conditional jump, but it may be the case that the various
hunks of fixup code aren't prepared to deal with that.

If you twiddle this code, you'll probably need to review all the fixup
related code in stmt.c very carefully, probably starting with
expand_goto_internal

 >or something similar.  Supporting evidence that this is all historical
 >code is that the alt_end_label field mentioned in the quoted code above
 >is only ever assigned values and never actually used!
It's certainly the case that the assignments to alt_end_label should just
go away.

 >Another strong argument that none of this is required, is the fact
 >that cfg_optimize reorganizes it long before most of the compiler
 >even sees it.
This certainly isn't an argument that it's historical -- it's merely the
case that after code generation is complete that we don't need this slightly
convoluted code.  Again, review the fixup related code in stmt.c.  It 
may insert code before the goto later during RTL generation.  

jeff