Refactor CodeGen Pipeline Setup into a Single Function - #162556
boomanaiden154 wants to merge 1 commit into
Conversation
|
Thanks for the pull request, and welcome! The Rust Project has assigned @cuviper (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks. Please see the contribution instructions and our LLM policy for more information. Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
This patch refactors setup of the LegacyPassManager for CodeGen into a single function. This simplifies some things (lifetime for the LegacyPM object), but is primarily aimed at enabling rustc to use the new runCodeGenPipeline abstraction (introduced in LLVM 24) which handles all of these details within LLVM and additionally defaults to the NewPM when a target opts-in/the correct LLVM flag is passed.
3d1a7ac to
55d2be6
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
There was a problem hiding this comment.
Note, this will conflict with #162822, but that will hopefully be easy to merge first and then rebase this PR.
| // Apparently `addPassesToEmitFile` adds a pointer to our on-the-stack output | ||
| // stream (OS), so the only real safe place to delete this is here? Don't we | ||
| // wish this was written in Rust? | ||
| LLVMDisposePassManager(PMR); |
There was a problem hiding this comment.
Isn't this destructor order still relevant? With PM declared first, it will now be deleted after OS and BOS, which is what that comment warned against.
|
Reminder, once the PR becomes ready for a review, use |
|
☔ The latest upstream changes (presumably #162827) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
This patch refactors setup of the LegacyPassManager for CodeGen into a single function. This simplifies some things (lifetime for the LegacyPM object), but is primarily aimed at enabling rustc to use the new runCodeGenPipeline abstraction (introduced in LLVM 24) which handles all of these details within LLVM and additionally defaults to the NewPM when a target opts-in/the correct LLVM flag is passed.