About the loop optimizer

["Eric Botcazou" <ebotcazou at libertysurf dot fr>]

1. While skimming through the code, I found this chunk in check_dbra_loop
   that seems to me completely bogus: (loop.c:7919)

  {
    /* If more than one condition is present to control the loop, then
       do not proceed, as this function does not know how to rewrite
       loop tests with more than one condition.

       Look backwards from the first insn in the last comparison
       sequence and see if we've got another comparison sequence.  */

    rtx jump1;
    if ((jump1 = prev_nonnote_insn (first_compare)) != loop->cont)
      if (GET_CODE (jump1) == JUMP_INSN)
        return 0;
  }

Firstly loop->cont is certainly a NOTE, so the first test is always true.
Hence the whole condition is equivalent to:

  if (GET_CODE (prev_nonnote_insn (first_compare)) == JUMP_INSN)
    return 0;

Secondly, this test is too narrow to catch all loop tests with more than one
condition (for instance, the previous insn could be a CODE_LABEL).

Therefore I think something like

  p = first_compare;
  while ((p = PREV_INSN (p)) != loop->cont)
    if (GET_CODE (p) == JUMP_INSN)
      return 0;

would be better. Should I try to write a testcase ?

2. There is a last remaining testsuite failure on i586-pc-linux-gnu caused
   by the loop optimizer:

FAIL: gcc.c-torture/execute/loop-2e.c execution,  -Os

This one is trickier than the others: it is the consequence of the
fundamental "unsafeness" of the induction variable elimination pass of the
loop optimizer. The semantics of a condition on a biv may get lost when the
biv is replaced by a giv which wraps around.

There is of course no other general fix than disabling the pass; however, in
a few particular cases (including the above testcase), the condition can be
rewritten so as to be "elimination-proof", but this would require a
substantial amount of code. Is this problem worth fixing ?

--
Eric Botcazou
ebotcazou@multimania.com