Re: [rtlopt] runtime iterations unrolling fix

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > > the test to disable exit conditional in peeled copy of loop body is
> > > reversed compared to the comment.  I guess the comment is what you've
> > > intended so I've changed it.  Still I am not able to come with
> > > testcase when we need exit test in all copies.  Can you enlighten me?
> > 
> > thinking about it, I come to belief the comment is the thing that is wrong --
> > suppose that we have a preincr loop, that means we are
> > trying to arrange things so that the exit from loop body is in the last
> > block of the loop; it is, we must arrange that after entering the body,
> > there will be -1 (mod # of unrollings) iterations left. I must have
> > tests for exit in every copy (in preconditioning), as we may exit
> > in some of these copies (in case the loops rolls less than # of
> > unrollings times).
> > 
> > So I will revert the change and fix the comment.
> > 
> > Did the code as it was cause some problem?
> I see what are you shooting for now, but it seems to be quite
> unnecesarily expensive way to do so.
> We have two problems - one problem is the case where loop is
> paradoxical, then we need one of the original exit tests to bail out in
> very first iteration.
> In the other cases we know the number of iterations to be valid, but
> still it can be set up in a way that the unrolled loops will iterate 0
> times, if I understand it correctly, you are keeping the exit test just
> for this case.
> It would be better to base exit condition only on the number of
> iterations that is anyway readilly available - keep the
> (niter&nuroll==x) tests in the peeled copies, removing exit tests and
> add one extra testst (niter >= nunroll) just preconditioning the loop.
> 
> Then we will execute in worst case npeelings+2 tests instead of
> 2*npeelings.

This will not work; there are two basic problems:
1) niter may come out negative due to overflow and then the last
comparison won't work.
2) more importantly, the exit does not neccesarily have to be at the end
of loop body (I use preincrement/postincremet test as a cheap heuristic
to where to place the loop exit, but there is no garantee). It would be
probably useful ta handle the common special case where it is
true in some way simmilar to what you suggest (handling (1) somehow).

Btw: the code in cfgloopanal.c:count_loop_iterations looks a bit strange to me:

if (stride != const1_rtx
    && (simplify_gen_binary (UMOD, GET_MODE (desc->var), exp, stride)
           != const0_rtx))
  return NULL;

how could the second part be not satisfied?

Should not we increase exp by stride rather than by 1 a few lines below?

Zdenek