Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for new LLVM pass manager (-Znew-llvm-pass-manager) #74705

Closed
3 of 4 tasks
dtolnay opened this issue Jul 24, 2020 · 9 comments
Closed
3 of 4 tasks

Tracking issue for new LLVM pass manager (-Znew-llvm-pass-manager) #74705

dtolnay opened this issue Jul 24, 2020 · 9 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented Jul 24, 2020

This is a tracking issue for rustc's use of the new LLVM pass manager, which is currently behind an unstable rustc flag -Znew-llvm-pass-manager but which we will presumably want to make default at the right time, just like Clang intends to do.

When building with -Znew-llvm-pass-manager, both the pre-link optimization and LTO pipelines use the new pass manager.

There are some bits that are not supported yet:

  • NewPM does not support PGO at O0 in LLVM 9. This is supported in LLVM 10. Fixed by Update to LLVM 10 #67759.
  • NewPM does not support MergeFunctions in LLVM 9. While it's supported in LLVM 10, it's not exposed as a PassBuilder option. We'll have to manually schedule the pass, or add that option upstream.
  • -C passes. NewPM requires an entirely different way of specifying custom pass pipelines. We should probably expose that functionality, but it doesn't directly map to what -C passes does.
  • NewPM has no support for custom inline parameters right now. We'd have to add upstream support for that first.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Implementation history

@dtolnay dtolnay added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Jul 24, 2020
@nikic
Copy link
Contributor

nikic commented Jul 24, 2020

NewPM does not support MergeFunctions in LLVM 9. We'll be able to re-enable that with LLVM 10.

While it's supported in LLVM 10, it's not exposed as a PassBuilder option. So we'd have to manually schedule the pass, or add that option upstream.

@hudson-ayers
Copy link
Contributor

Should this be closed by #88243 ?

@cuviper
Copy link
Member

cuviper commented Oct 4, 2021

Well, the -Z option still exists, just defaulting to "yes" now for LLVM >= 13.

@pnkfelix
Copy link
Member

At this point I don't think this tracking issue is serving much purpose. My understanding is that LLVM 15 has removed support for the old pass manager.

I do see that the -Z flag is still around. I don't know if that's to accommodate users who are linking to an older version of LLVM. (I also don't know if such a scenario is tested in our CI or supported at any level.)

I'm going to close this issue; future work on what do to with the aforementioned -Z flag can follow the MCP process (or we can probably go straight to removing it in a Pull Request if I'm right that it doesn't make sense to continue offering it).

@cuviper
Copy link
Member

cuviper commented Sep 16, 2022

LLVM 13 is now our minimum, and we default to newPM everywhere -- except on s390x due to #89609, where that was only resolved in LLVM 14 since #94764. If it weren't for that, I'd say go ahead and remove the option, along with all of the code supporting oldPM.

I have a local branch for updating the minimum to LLVM 14, and while I don't think we're ready for that quite yet, I can add this removal to my branch so I won't forget later. :)

@cuviper
Copy link
Member

cuviper commented Sep 16, 2022

Here's a preview git diff --stat, not bad! 🙂

 Cargo.lock                                                      |   1 -
 compiler/rustc_codegen_llvm/Cargo.toml                          |   1 -
 compiler/rustc_codegen_llvm/src/back/lto.rs                     |  63 ++-----------
 compiler/rustc_codegen_llvm/src/back/write.rs                   | 258 +++--------------------------------------------------
 compiler/rustc_codegen_llvm/src/lib.rs                          |   2 +-
 compiler/rustc_codegen_llvm/src/llvm/ffi.rs                     |  74 +--------------
 compiler/rustc_codegen_llvm/src/llvm_util.rs                    |  29 +-----
 compiler/rustc_codegen_ssa/src/back/write.rs                    |   2 -
 compiler/rustc_interface/src/tests.rs                           |   1 -
 compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp                | 235 +-----------------------------------------------
 compiler/rustc_session/src/options.rs                           |   2 -
 src/doc/unstable-book/src/compiler-flags/self-profile-events.md |   2 +-
 src/test/rustdoc-ui/z-help.stdout                               |   1 -
 src/test/ui/invalid/invalid-llvm-passes.rs                      |   2 +-
 src/test/ui/sanitize/new-llvm-pass-manager-thin-lto.rs          |   2 +-
 15 files changed, 24 insertions(+), 651 deletions(-)

@nikic
Copy link
Contributor

nikic commented Sep 17, 2022

I think it would be fine to drop legacy PM support without dropping LLVM 13 support. That just means that the particular combination of s390x + LLVM 13 may have some issues -- but I don't think we're obligated to care given that this is both a tier 2 architecture and an old LLVM version. I'd even expect that that particular intersection (s390x + llvm13 + nightly rustc) has exactly zero users.

@mati865
Copy link
Contributor

mati865 commented Sep 18, 2022

Also this is an unstable flag that is unusable on stable (at least without hacks) and vendors typically only provide stable toolchains.

@cuviper
Copy link
Member

cuviper commented Sep 18, 2022

I'd even expect that that particular intersection (s390x + llvm13 + nightly rustc) has exactly zero users.

It still matters for stable since the implicit fallback behavior happens without the unstable option, and for example Fedora 35 is a downstream that builds on LLVM 13. I don't know how active Fedora s390x really is, nor if any other distros care. For that matter, Fedora 35 EOL will be around the end of November, before the current 1.66 nightly releases on December 15.

I'll go ahead and open a PR for it, and we can see if there's any objection.

fee1-dead added a commit to fee1-dead-contrib/rust that referenced this issue Sep 25, 2022
Remove support for legacy PM

This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does.

cc rust-lang#74705
r? ``@nikic``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants