Page MenuHomePhabricator

[New PM][IRCE] port of Inductive Range Check Elimination pass to the new pass manager
ClosedPublic

Authored by fedor.sergeev on Feb 26 2018, 4:19 PM.

Details

Summary

[New PM][IRCE] port of Inductive Range Check Elimination pass to the new pass manager

There are two nontrivial details here:
* Loop structure update interface is quite different with new pass manager,
  so the code to add new loops was factored out

* BranchProbabilityInfo is not a loop analysis, so it can not be just getResult'ed from
  within the loop pass. It cant even be queried through getCachedResult as LoopCanonicalization
  sequence (e.g. LoopSimplify) might invalidate BPI results.

  Complete solution for BPI will likely take some time to discuss and figure out,
  so for now this was partially solved by making BPI optional in IRCE
  (skipping a couple of profitability checks if it is absent).

Most of the IRCE tests got their corresponding new-pass-manager variant enabled.
Only two of them depend on BPI, both marked with TODO, to be turned on when BPI
starts being available for loop passes.

Diff Detail

Event Timeline

fedor.sergeev created this revision.Feb 26 2018, 4:19 PM

I'm not happy with BPI solution in this patch.
It is mainly to provoke discussions on how to solve this more gracefully, since no answers were given on llvm-dev@ :

http://lists.llvm.org/pipermail/llvm-dev/2018-January/120768.html

And yes, we want to have IRCE in new-pass-manager for our internal pipeline...

This revision is now accepted and ready to land.Mar 11 2018, 10:44 PM

Not familiar with the details here, adding a couple of formatting nits.

include/llvm/Transforms/Scalar/LoopPassManager.h
307 ↗(On Diff #136006)

clang-format?

lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp
45–46

Alphabetical order of includes?

lib/Transforms/Scalar/LoopDistribute.cpp
998 ↗(On Diff #136006)

clang-format (whole patch)

I'm not happy with BPI solution in this patch.
It is mainly to provoke discussions on how to solve this more gracefully, since no answers were given on llvm-dev@ :

http://lists.llvm.org/pipermail/llvm-dev/2018-January/120768.html

And yes, we want to have IRCE in new-pass-manager for our internal pipeline...

Sorry for delays getting to this. Generally the approach seems fine to me.

I would just suggest making BPI required as part of the loop standard analyses. It should be a separate patch (with clear discussion pointing out why it is useful), but BPI is useful to *many* loop passes I suspect, I just think we hadn't wired it up previously.

As part of this we should do some basic testing to make sure that the loop passes preserve BPI correctly.

lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp
603

Use LLVM naming conventions?

1773

Use LLVM-style naming?

1790

I'd use a commented out parameter name to make it more clear what is being ignored.

fedor.sergeev added inline comments.Mar 12 2018, 12:21 PM
lib/Transforms/Scalar/InductiveRangeCheckElimination.cpp
45–46

This is a "Main Module Header" according to llvm coding standard, so it should go first.
Unless I'm misreading.

lib/Transforms/Scalar/LoopDistribute.cpp
998 ↗(On Diff #136006)

I believe this funny indentation of LI, SE above was created exactly by clang-format.
I would write it differently if it was just me ;)

And yes, I will rerun clang-format on a whole patch once more to see if I missed anything.

I would just suggest making BPI required as part of the loop standard analyses.
It should be a separate patch (with clear discussion pointing out why it is useful), but BPI is useful to *many* loop passes I suspect, I just think we hadn't wired it up previously.

Should this separate BPI patch go before or after this change?

As part of this we should do some basic testing to make sure that the loop passes preserve BPI correctly.

Checking -debug-pass-manager output for "Running analysis:" and absence of "Invalidating analysis:", right?

I would just suggest making BPI required as part of the loop standard analyses.
It should be a separate patch (with clear discussion pointing out why it is useful), but BPI is useful to *many* loop passes I suspect, I just think we hadn't wired it up previously.

Should this separate BPI patch go before or after this change?

I think before.

As part of this we should do some basic testing to make sure that the loop passes preserve BPI correctly.

Checking -debug-pass-manager output for "Running analysis:" and absence of "Invalidating analysis:", right?

I think you'll also need to do some deeper testing ... possibly by verifying BPI between each loop pass?

We need to have a better mechanism for doing this than we currently have, especially for the loop standard passes

fedor.sergeev added inline comments.Mar 12 2018, 12:42 PM
include/llvm/Transforms/Scalar/LoopPassManager.h
307 ↗(On Diff #136006)

Hrm... double-checked, and clang-format explicitly wants BPI to go on the next line, even if I put it on the same line with MSSA.
Everything in this patch appears to go unchanged with clang-format except InitializePasses.h (which I keep its own way for consistency).

I think before.

Ok.

As part of this we should do some basic testing to make sure that the loop passes preserve BPI correctly.

Checking -debug-pass-manager output for "Running analysis:" and absence of "Invalidating analysis:", right?

I think you'll also need to do some deeper testing ... possibly by verifying BPI between each loop pass?

I'm afraid I do not fully get what kind of verification you are after.
But we can discuss it in that separate patch. Hopefully soon :)

fedor.sergeev planned changes to this revision.Mar 12 2018, 3:16 PM

It appears that turning BPI analysis into the standard one might prove to be rather costly (as that will cause this analysis to be run for every loop pass manager invocation, and currently there are none of the loop passes that use BPI in default pipelines).
I will craft a version of this patch that makes BPI completely optional in IRCE w/o any changes to LoopPassManager.
That will allow to decouple IRCE port from (a rather nonobvious) solution for BPI.

making BPI completely optional (removing all the LPM changes), cleanup

This revision is now accepted and ready to land.Mar 12 2018, 4:00 PM
fedor.sergeev edited the summary of this revision. (Show Details)Mar 12 2018, 4:02 PM
fedor.sergeev marked 3 inline comments as done.

If anybody has any other comments/objectsions, please, speak up.
I'm going to push this tomorrow.

This revision was automatically updated to reflect the committed changes.