-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
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. |
Should this be closed by #88243 ? |
Well, the |
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 I'm going to close this issue; future work on what do to with the aforementioned |
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. :) |
Here's a preview
|
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. |
Also this is an unstable flag that is unusable on stable (at least without hacks) and vendors typically only provide stable toolchains. |
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. |
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``
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.-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.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
The text was updated successfully, but these errors were encountered: