[RFC] Heuristic for complete loop unrolling

Hal Finkel hfinkel at anl.gov
Sat Jan 24 06:44:16 PST 2015


[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 ;)

+        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?

   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.

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




More information about the llvm-commits mailing list