Hi Michael,<br><br><div>This looks very much like the inner loops from convolve() in Geekbench... ;)</div><div><br></div><div>Interestingly if we reroll that loop nest, the number of instructions inside goes down by a factor of 3 so we do decide to inline them all. But that is just luck / a hack. I completely agree that our current unrolling heuristics don't take the right things into account (our inlining heuristics are similar!).<br><br>When thinking about this previously, I've been worried that there's a slippery slope where you could end up implementing half of the rest of the compiler's analysis passes in the unroller/inliner to check for opportunities. Do you have any thoughts on that? How do we keep it under control?</div><div><br></div><div>cc'ing Kevin who has been doing a lot of work recently on the loop unroller.</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div><br><div class="gmail_quote">On Fri Jan 23 2015 at 8:52:30 PM Michael Zolotukhin <<a href="mailto:mzolotukhin@apple.com">mzolotukhin@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi devs,<br>
<br>
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:<br>
<br>
for(y = 0..height) {<br>
 for (x = 0..width) {<br>
   val = 0<br>
   for (j = 0..5) {<br>
     for (i = 0..5) {<br>
       val += img[x+i,y+j] * weight[i,j]<br>
     }<br>
   }<br>
 }<br>
}<br>
<br>
And ‘weight' is just a constant matrix with some coefficients.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I can imagine that it might be also useful for computations, involving sparse constant matrixes (like identity matrix).<br>
<br>
The attached patch implements this feature, and with it we handle the original testcase well.<br>
<br>
<br>
<br>
Does it look good? Of course, any ideas, suggestions and other feedback are welcome!<br>
<br>
<br>
Thanks,<br>
Michael______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div>