Re: [PATCH] Improve initial RTL generation for loops

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

In message <Pine.LNX.4.33.0209111536250.5936-100000@www.eyesopen.com>, Roger Sa
yle writes:
 >
 >> > 2002-09-10  Roger Sayle  <roger@eyesopen.com>
 >> >
 >> >	* stmt.c (expand_end_loop):  Don't rotate the loop when there
 >> >	are no instructions in the test, i.e. the loop is unconditional.
 >> >	(expand_exit_loop_if_false):  Optimize RTL generation of loop
 >> >	tests when the condition is always true or always false.
 >> >	* c-semantics.c (genrtl_do_stmt):  Optimize RTL generation of
 >> >	do-loops when the condition is always true.
 >> >	(genrtl_for_stmt):  Optimize RTL gen.eration of for-loops when
 >> >	the for-expression is empty.
 >>
 >> My only concern is that we may not be handling fixups correctly; don't
 >> we still potentially need to expand fixups for a loop with a always-false
 >> condition when we leave the loop nesting?  If so, does that work properly?
 >
 >Thanks for the warning.  I've just rechecked my patch with respect
 >to fix-up issues.  Fortunately, if the loop condition is true, we
 >don't output a jump so nothing needs to be fixed up.  If the condition
 >is always false, we call expand_exit_loop, which takes care of the
 >fixups for us.
OK.   Good.


 >The potential problems with fixups only occur with conditional branches
 >such that one edge exits the loop and the other doesn't.  In this case
 >any additional code required to correct the stack on exit can't be placed
 >immediately of the conditional jump (because it'll be executed for both
 >the taken and untaken paths).  Hence, the reason for the jump over jump!
 >Unconditional jumps out of loops don't have this problem.
OK.  Another thought to improve this would be to go ahead and build
the loop in the simple manner, construct the CFG, then have the
fixup code use insert_insn_on_edge.  That would probably avoid most
of these problems.

 >I now see that you're right that I can't just replace the "jump over
 >jump" completely.  However, we could try and spot cases where the
 >exit label is already known, so we can check whether any fixup code
 >is required.
Given that we have the entire loop structure in tree form we could
probably analyze that to determine if there are going to be any fixups.

This didn't work in the past due to the statement at a time nature of
the tree->rtl conversion process that GCC used to have.

jeff