[RFC] Heuristic for complete loop unrolling

[Michael Zolotukhin]

Hi Hal,

Thanks for the review! Please see my comments inline.

> On Jan 24, 2015, at 6:44 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> [moving patch review to llvm-commits]
> 
> +static bool CanEliminateLoadFrom(Value *V) {
> 
> +  if (Constant *C = dyn_cast<Constant>(V)) {
> 
> +    if (GlobalVariable *GV = dyn_cast<GlobalVariable>(C))
> 
> +      if (GV->isConstant() && GV->hasDefinitiveInitializer())
> 
> 
> Why are you casting to a Constant, and then to a GlobalVariable, and then checking GV->isConstant()? There seems to be unnecessary redundancy here ;)
Indeed:)

> +        return GV->getInitializer();
> 
> +  }
> 
> +  return false;
> 
> +}
> 
> +static unsigned ApproximateNumberOfEliminatedInstruction(const Loop *L,
> 
> +                                                         ScalarEvolution &SE) {
> 
> This function seems mis-named. For one thing, it is not counting the number of instructions potentially eliminated, but the number of loads. Eliminating the loads might have lead to further constant propagation, and really calculating the number of eliminated instructions would require estimating that effect, right?
That’s right. But I’d rather change the function name, than add such calculations, since it’ll look very-very narrow targeted, and I worry that we might start to lose some cases as well. How about ‘NumberOfConstantFoldedLoads’?

>   if (TripCount && Count == TripCount) {
> 
> -    if (Threshold != NoThreshold && UnrolledSize > Threshold) {
> 
> +    if (Threshold != NoThreshold && UnrolledSize > Threshold + 20 * ElimInsns) {
> 
> 
> 20, huh? Is this a heuristic for constant propagation? It feels like we should be able to do better than this.
Yep, that’s a parameter of the heuristic. Counting each ‘constant' load as 1 is too conservative and doesn’t give much here, but since we don’t actually count number of eliminated instructions we need some estimate for it. This estimate is really rough, since in some cases we can eliminate the entire loop body, while in the others we can’t eliminate anything.

I’d really appreciate a feedback on how to model this in a better way.

Thanks,
Michael
> 
> Thanks again,
> Hal
> 
> ----- Original Message -----
>> From: "Michael Zolotukhin" <mzolotukhin at apple.com>
>> To: "LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)" <llvmdev at cs.uiuc.edu>
>> Cc: "Hal J. Finkel" <hfinkel at anl.gov>, "Arnold Schwaighofer" <aschwaighofer at apple.com>
>> Sent: Friday, January 23, 2015 2:05:11 PM
>> Subject: [RFC] Heuristic for complete loop unrolling
>> 
>> 
>> 
>> Hi devs,
>> 
>> Recently I came across an interesting testcase that LLVM failed to
>> optimize well. The test does some image processing, and as a part of
>> it, it traverses all the pixels and computes some value basing on
>> the adjacent pixels. So, the hot part looks like this:
>> 
>> for(y = 0..height) {
>> for (x = 0..width) {
>> val = 0
>> for (j = 0..5) {
>> for (i = 0..5) {
>> val += img[x+i,y+j] * weight[i,j]
>> }
>> }
>> }
>> }
>> 
>> And ‘weight' is just a constant matrix with some coefficients.
>> 
>> If we unroll the two internal loops (with tripcount 5), then we can
>> replace weight[i,j] with concrete constant values. In this
>> particular case, many of the coefficients are actually 0 or 1, which
>> enables huge code simplifications later on. But currently we unroll
>> only the innermost one, because unrolling both of them will exceed
>> the threshold.
>> 
>> When deciding whether to unroll or not, we currently look only at the
>> instruction count of the loop. My proposal is to, on top of that,
>> check if we can enable any later optimizations by unrolling - in
>> this case by replacing a load with a constant. Similar to what we do
>> in inlining heuristics, we can estimate how many instructions would
>> be potentially eliminated after unrolling and adjust our threshold
>> with this value.
>> 
>> I can imagine that it might be also useful for computations,
>> involving sparse constant matrixes (like identity matrix).
>> 
>> The attached patch implements this feature, and with it we handle the
>> original testcase well.
>> 
>> 
>> 
>> 
>> 
>> Does it look good? Of course, any ideas, suggestions and other
>> feedback are welcome!
>> 
>> 
>> Thanks,
>> Michael
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150124/0a8b1a95/attachment.html>