[PATCH] D156532: [Pipelines] Perform hoisting prior to GVN

[Dave Green via Phabricator via llvm-commits]

dmgreen added a comment.

Hello. I ran some tests for moving the SimplifyCFG to after LPM2. The version that added an extra run of SimplifyCFG after LPM2 probably performed the best and showed the least decreases. There might be other cases that just don't come up in these benchmarks of course. The version that moved the existing LoopSimplify did a little worse in places and showed more ups and downs.
But.. I am worried it feels a little fragile for the quant case to be relying on it not optimizing prior to unrolling. In the long run we can probably simplify it, unroll and rely on the SLP vectorizer if it can add runtime checks, but I was looking at whether it made sense to disable unrolling in some cases too.

> Yeah, fully unrolling a loop with interior (that is, non-exit) control flow is probably significantly less profitable than unrolling without interior control flow, because the latter gives you straight-line code (or at least an extended basic block, if there are multiple exits). That seems like something we should take into account during cost modelling, but currently don't.

I had a look at disabling unrolling in the FullUnrollPass for loops with multiple exits. The existing heuristics are often quite.. rough at times. It was probably mostly OK, but I wasn't super enthused by the results and apparently in cases like this it is important to be able to unroll the outer loop so the inner loop can vectorize: https://godbolt.org/z/n6W8Tbdrf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156532