Re: unrolling and peeling decisions

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

Hello.

> And found interesting thing that we predict it to iterate 5 times, peel it 1
> time and don't unroll even with -funroll-all-loops.  This is somewhat creazy,
> as I would like to see it preconditionoed over iter, unrolled and probably not
> peeled.
> 
> About the number of iterations, without profile, I think we can't do much better.
> We predict all loops to iterate 5 or 11 times (depending whether they do have
> multiple exits or not) and that corresponds to the average number of iterations
> as measured by Andrea's tester.

Well, the problem is that I (wrongly) compare predicted number of iterations
with maximum number of unrollings/peelings, not the actual maximum for given
loop; the fix is easy (in unroll-new.c:732 and 818 replace with npeel/nunroll).
I can't do it here; if you want to, change it (or I will do it on Tuesday).

> Anyway I think deciding to peel 1 time is sick.  The decision is based on number
> of instructions in the loop.  I think better we should try hether we can peel
> the expected number of iterations of the loop w/o exceeding the maximal
> amount of instructions.  If so, then peel.  I am not sure if we can do that without
> profile feedback, but for feedback, this is definitly the way.

And this (aproximately) is what it would do, if I haven't made the mistake.

> Without feedback, I guess we need better analysis than we do now and peel only
> when we can prove fixed amount of iterations to be low or the loop simplifies
> by peeling as first few iterations are exceptional.  Lets postnote this at the moment.
> 
> Also the unrolling heuristics I think needs to be tweaked.  Why it disqualify
> the loop from unrolling?  I see that expected number of iterations is low, but
> w/o profile when we are asked for unrolling I guess we should unroll anyway.

Do as you wish.

> Also I would like to see the loop to match simple_loop.  Why do you prohibit
> the loop to have multiple exits?  Even when it has multiple of them and it has
> one, that is "well behaved" - postdominated by latch (executed each iteration)
> and executed maximally once (how can we easilly determine this?), we still
> can compute maximal number of iterations and use it as base for unrolling and
> preconditioning.

Simple_loop is used to check that we are able to calculate number of iterations
exactly; this loop does not fit into the cathegory. I don't see use for upper
bound on number of iterations, please explain more precisely.

Zdenek