Rewrite pass management with LLVM #8700
Conversation
|
I don't really understand the interface suface well enough, but I thought we used to do something like this and then switched to the explicit pass-list. Are we switching back, or ... "to something else entirely"? |
|
@graydon: We used to do something like this but the C API was missing many needed features so it wasn't done correctly (no function pass, no loop-vectorize, etc.). It was worked around by manually specifying the passes, but in hindsight that's just too much effort to keep up-to-date compared to using the C++ API (and still missing the function pass). @alexcrichton: needs a rebase |
|
This does slightly revert back to the "old behavior", and I agree with @thestinger that we probably shouldn't have moved off of it in the first place. Another reason we moved away was for a more customizable pipeline, but this retains all the customizability of the pipeline. Otherwise rebased. |
|
Not sure what is wrong :( |
|
@alexcrichton: can you verify that we're still able to add a pass to a specific phase of optimization? for example, a |
|
I've verified that you can add custom passes, but right now they're all added at the end of the pipeline. I supposed we could have I'm also confused as to the problem, it appears that I'm configuring LLVM incorrectly on ARM so it doesn't think that it's either linux or android. I'm going to have to research that by getting a local android checkout (never done this before). |
|
Turns out I wasn't calling |
Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops` All of these "copies" of clang are based off their [source code](http://clang.llvm.org/doxygen/BackendUtil_8cpp_source.html) in case anyone is curious what my source is. I was hoping that this would fix #8665, but this does not help the performance issues found there. Hopefully i'll allow us to tweak passes or see what's going on to try to debug that problem.
Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops`
Beforehand, it was unclear whether rust was performing the "recommended set" of optimizations provided by LLVM for code. This commit changes the way we run passes to closely mirror that of clang, which in theory does it correctly. The notable changes include: * Passes are no longer explicitly added one by one. This would be difficult to keep up with as LLVM changes and we don't guaranteed always know the best order in which to run passes * Passes are now managed by LLVM's PassManagerBuilder object. This is then used to populate the various pass managers run. * We now run both a FunctionPassManager and a module-wide PassManager. This is what clang does, and I presume that we *may* see a speed boost from the module-wide passes just having to do less work. I have no measured this. * The codegen pass manager has been extracted to its own separate pass manager to not get mixed up with the other passes * All pass managers now include passes for target-specific data layout and analysis passes Some new features include: * You can now print all passes being run with `-Z print-llvm-passes` * When specifying passes via `--passes`, the passes are now appended to the default list of passes instead of overwriting them. * The output of `--passes list` is now generated by LLVM instead of maintaining a list of passes ourselves * Loop vectorization is turned on by default as an optimization pass and can be disabled with `-Z no-vectorize-loops` All of these "copies" of clang are based off their [source code](http://clang.llvm.org/doxygen/BackendUtil_8cpp_source.html) in case anyone is curious what my source is. I was hoping that this would fix #8665, but this does not help the performance issues found there. Hopefully i'll allow us to tweak passes or see what's going on to try to debug that problem.
|
This appeared to cause a few percent slowdown in both the bootstrap and testsuite. |
|
Hmm, I'd want to investigate whether this is a slowdown in compilation time or runtime. If it's the latter then it's a serious problem, the former might indicate that we should tweak the passes that we run slightly. This does warrant further investigation, though. |
|
hides behind pcwalton's huge gains |
…ve, r=xFrednet Fix needless_match false positive for if-let when the else block doesn't match to given expr <!-- Thank you for making Clippy better! We're collecting our changelog from pull request descriptions. If your PR only includes internal changes, you can just write `changelog: none`. Otherwise, please write a short comment explaining your change. Also, it's helpful for us that the lint name is put into brackets `[]` and backticks `` ` ` ``, e.g. ``[`lint_name`]``. If your PR fixes an issue, you can add "fixes #issue_number" into this PR description. This way the issue will be automatically closed when your PR is merged. If you added a new lint, here's a checklist for things that will be checked during review or continuous integration. - \[ ] Followed [lint naming conventions][lint_naming] - \[ ] Added passing UI tests (including committed `.stderr` file) - \[x] `cargo test` passes locally - \[x] Executed `cargo dev update_lints` - \[ ] Added lint documentation - \[x] Run `cargo dev fmt` [lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints Note that you can skip the above if you are just opening a WIP PR in order to get feedback. Delete this line and everything above before opening your PR. ---> fix rust-lang#8695 *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: Fixed ``[`needless_match`]`` false positive when else block expression differs.
Beforehand, it was unclear whether rust was performing the "recommended set" of
optimizations provided by LLVM for code. This commit changes the way we run
passes to closely mirror that of clang, which in theory does it correctly. The
notable changes include:
keep up with as LLVM changes and we don't guaranteed always know the best
order in which to run passes
to populate the various pass managers run.
what clang does, and I presume that we may see a speed boost from the
module-wide passes just having to do less work. I have no measured this.
to not get mixed up with the other passes
analysis passes
Some new features include:
-Z print-llvm-passes--passes, the passes are now appended to thedefault list of passes instead of overwriting them.
--passes listis now generated by LLVM instead of maintaininga list of passes ourselves
disabled with
-Z no-vectorize-loopsAll of these "copies" of clang are based off their source code in case anyone is curious what my source is. I was hoping that this would fix #8665, but this does not help the performance issues found there. Hopefully i'll allow us to tweak passes or see what's going on to try to debug that problem.