cg_llvm: Clean up FFI calls for operand bundles by Zalathar · Pull Request #132342 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation16 Commits1 Checks6 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
All of these FFI functions have equivalents in the stable LLVM-C API, though LLVMBuildCallBr requires a temporary polyfill on LLVM 18.
This PR also creates a clear split between OperandBundleOwned and OperandBundle, and updates the internals of the owner to be a little less terrifying.
rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
Oh boo, that makes things a bit more complicated. Thanks for the pointer.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Rather than back out the switch to LLVMBuildCallBr, I've renamed the old LLVMRustBuildCallBr to be a polyfill for that function, for LLVM 18 only.
So after the next LLVM bump when 19 becomes baseline, the polyfill can just be deleted.
In discussions elsewhere there was some brief confusion over whether the requirement should be 19.0 or 19.1.
It turns out that LLVM has switched to a policy of making their first release in a series X.1, to distinguish it from development builds prior to the release process: https://discourse.llvm.org/t/rfc-name-the-first-release-from-a-branch-n-1-0-instead-of-n-0-0/75384.
I'm going to stick with <19.0 as the condition for the polyfill, because I'd rather err on the side of not having the polyfill. If someone really wants to try building against prerelease LLVM 19 for some reason, whether or not that works is their problem.
Looks like the polyfill works in PR CI.
@rustbot ready
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Comment on lines +335 to +337
| /// Owns an [`OperandBundle`], and will dispose of it when dropped. |
|---|
| pub(crate) struct OperandBundleOwned<'a> { |
| raw: ptr::NonNull<OperandBundle<'a>>, |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, and the dependence on the &[&'a Value] is what means we can't just make OperandBundleOwned be actually this, right?
type OperandBundleOwned = OperandBundle<'static>;
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, from what I can tell an operand bundle holds copies of the value pointers internally, so it would be unsound for the bundle to outlive those values.
(In practice, I think the lifetime of values is always 'll, i.e. the lifetime of the LLVM context.)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh one other relevant point, OperandBundleOwned is closer to Box<OperandBundle>, since its representation is a pointer to the underlying bundle, and the owner is responsible for deallocating on drop.
So the two types would still have to be different, unless we hypothetically had &own references to handle dropping.
📌 Commit c307159 has been approved by workingjubilee
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
…iaskrgr
Rollup of 8 pull requests
Successful merges:
- rust-lang#129394 (Don't lint
irrefutable_let_patternson leading patterns ifelse iflet-chains) - rust-lang#131856 (TypingMode: merge intercrate, reveal, and defining_opaque_types)
- rust-lang#132322 (powerpc64-ibm-aix: update maintainters)
- rust-lang#132327 (Point to Fuchsia team in platform support docs)
- rust-lang#132332 (Use
token_descrmore in error messages) - rust-lang#132338 (Remove
Engine) - rust-lang#132340 (cg_llvm: Consistently use safe wrapper function
set_section) - rust-lang#132342 (cg_llvm: Clean up FFI calls for operand bundles)
r? @ghost
@rustbot modify labels: rollup
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#132342 - Zalathar:operand-bundle, r=workingjubilee
cg_llvm: Clean up FFI calls for operand bundles
All of these FFI functions have equivalents in the stable LLVM-C API, though LLVMBuildCallBr requires a temporary polyfill on LLVM 18.
This PR also creates a clear split between OperandBundleOwned and OperandBundle, and updates the internals of the owner to be a little less terrifying.
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.