[Bug tree-optimization/37239] peeling last iteration of a <= loop

["matz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239

--- Comment #8 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> While hmmer is now split the testcase in this bug isn't.  We do find some
> split points but appearantly never split the loop.

This is not a case for normal loop splitting.  The loop in question has
multiple exits.  The potential split point that is found is in the loop in
question,
but relative to the outer loop:

    for (  qty--; i >  0; i--) siftDown  (numbers, i, qty);

which inline-expanded looks somewhat like:

  for (  qty--; i >  0; i--)
    top = i, maxIdx = i, last = qty;
    while (last >= (maxIdx += maxIdx)) {

        /* This is where the comparison occurrs and where a sufficiently
           good compiler can use a computed conditional result rather
           than using control logic. */
        if (maxIdx != last && numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++;

        if (tmp >= numbers[maxIdx]) break;
        numbers[top] = numbers[maxIdx];
        top = maxIdx;
    }

The potential split point is the pre-header check if the inner loop is to
be entered at all (i.e. "last >= 2*maxIdx").  The outer loop isn't split
because i and 2*maxIdx (aka 2*i) don't have the same steps.

Of course even if we'd split the outer loop we wouldn't gain anything here.

Also note that the wanted transformation isn't exactly peeling the last
iteration.  The last iteration must only be entered if the non-normal exit
isn't taken.  Dealing with all that is currently not implemented.