[PATCH] D104636: [LoopIdiom] [LoopNest] let the pass deal with runtime memset size

Yueh-Ting Chen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 26 03:28:17 PDT 2021


eopXD added inline comments.


================
Comment at: llvm/test/Transforms/LoopIdiom/memset-runtime.ll:36
+
+for.cond1.preheader:                              ; preds = %for.inc4, %entry
+  %i.017 = phi i64 [ 0, %entry ], [ %inc5, %for.inc4 ]
----------------
fhahn wrote:
> I'm not sure if I am missing something, but this test has just a single loop, so it's a 'trivial' loop nest, right?
> 
>  Couldn't this case be handled without making it a loop nest pass, by just checking if there's no parent loop? And even if there's a parent loop, wouldn't it also be possible to transform the inner loop to a wider memset, without the parents being perfectly nested?
Yes you are right. This example does not show why LoopNest is needed.

Current LIR only deals with constant store size (or memset size). This patch uses SCEV to let LIR deal with runtime sizes. If we deal with runtime sizes, we will need to add runtime check for it.

```
if (runtime_check) {
  //optimized code
} else 
  // code that does not optimize runtime variables
}
```

With LIR, we can certainly transfer loops from inner loop to a wider one until it reaches the outer most. However if we perform it layer by layer, the total versions created will increase exponentially. To prevent this from happening, we create only 1 if-else for versioning at the top-loop. This is where LoopNest comes in.

Thank you for reminding, I shall add an example to show this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104636/new/

https://reviews.llvm.org/D104636



More information about the llvm-commits mailing list