Re: Help w/ CFG/loop optimization problem?

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 11 Sep 2002, Jeff Law wrote:
>  >I think I know a possible fix.  I believe that the "conditional branch
>  >over an unconditional branch" idiom that GCC's initial RTL generation
>  >uses is a historical artifact.  I suspect that GCC now handles long
>  >conditional branches perfectly well,  so creating jumps over jumps
>  >does nothing but confuse CFG, which in turn confuses LOOP.
>
> Hmm, I doubt this had anything at all to do with long branches, but is
> more an artifact of GCC's often simple-minded code generator (and to
> a lesser extent these things can happen due to other optimizations).
>
> Long branch support is dealt with *much* later in the compiler --
> during final assembly output.
>
> I'd be surprised if this optimization could really just "go away"; I
> don't recall any changes in the base code generator which would avoid
> generating such code.

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'm almost certain this is an historical accident, and the RTL could
be expressed much cleaner when generated using the following line:

  do_jump (cond, whichloop->data.loop.end_label, NULL_RTX);

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!

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.


I'm happy to develop a patch to correct this, once my current patch to
expand_loop_exit_if_false is reviewed (otherwise the changes conflict).

Roger
--