Make InductiveRangeCheckElimination a FunctionPass.
Two drive-by comments only.
I know this is not your code but I fail to see why the LPMAddNewLoop is different here from below. If it wasn't we could merge almost all of the run code into a common helper.
Nit: Loops is not the right name anymore.
Hi Max, please see https://groups.google.com/forum/#!topic/llvm-dev/pOMjqRYZRQ0. I didn't have an up-to-date email address, so the emails cc-ed to you bounced.
My main motivation is that we need BFI computed from scratch, as it's not being preserved. The new pass manager will disallow getting a cached analysis that can be invalidated, in order to avoid hidden bugs (happy to elaborate here). This patch is rebased on top of D72891, which removes the getCachedResult for BFI.
I don't have the context for how IRCE is used, on its own or along with other loop passes, that's why I sent out the RFC, hoping to get some clarifications. Please also see the thread of making LoopUnrollAndJam a Function pass.
Thanks for clarification. We currently use IRCE in a loop pipeline along with LoopSimplifyCFG only. I think the only motivation for this was an attempt to save some compile time. Looks like it won't harm if we run them in different pipelines, I don't think there would be difference.
Fine by me.
I don't think, as a Function pass we need to promise preserving LCSSA. In the LoopPassManager (if this was a Loop pass), the two passes (simplify and lcssa) are run to canonicalize the loop. This is the only purpose of running these passes here.
The ArrayRef version above requires an ArrayRef&, so I'd need to allocate a container at the callsite.
Unit tests: pass. 62428 tests passed, 0 failed and 845 were skipped.
clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch.
Unit tests: unknown.