Repository navigation
Conversation
|
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Any special-casing of Miri in the standard library requires review. cc @rust-lang/miri
cc @rust-lang/miri |
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
FWIW our policy disallows code generation, and there is no exception for tests. For those you're supposed to have a pre-arranged reviewer who agreed to reviewing LLM code. |
|
Oh right, I'll close this and open a new pr with tests made by me If that's okay |
|
You can also update this PR. Or you can make it a draft and ask for a reviewer on Zulip. Whatever you prefer. |
| #[unstable(feature = "uint_gather_scatter_bits", issue = "149069")] | ||
| #[rustc_const_unstable(feature = "uint_gather_scatter_bits", issue = "149069")] | ||
| #[miri::intrinsic_fallback_is_spec] | ||
| pub const fn pext<T: [const] fallback::Pext>(x: T, mask: T) -> T { |
There was a problem hiding this comment.
These names are extremely opaque and make little sense to me.
Please name intrinsics more like the Rust operation than their often obscure LLVM name. You can mention the LLVM name in the docs.
b457daf to
50266b1
Compare
This comment has been minimized.
This comment has been minimized.
50266b1 to
3e22e48
Compare
|
r? RalfJung |
|
|
There was a problem hiding this comment.
This seems reasonable, modulo some nits.
@rust-lang/wg-llvm any concerns about using these new LLVM intrinsics?
@rustbot author
| let pair = self.insert_value(pair, high, 1); | ||
| pair | ||
| } | ||
| sym::deposit_bits | sym::extract_bits if llvm_version >= (23, 0, 0) => { |
There was a problem hiding this comment.
Why are we only using this for LLVM >= 23? Please add a comment.
|
|
||
| #[inline(always)] | ||
| pub(in crate::num) const fn extract_impl(mut x: $U, sparse: $U) -> $U { | ||
| pub(crate) const fn extract_impl(mut x: $U, sparse: $U) -> $U { |
There was a problem hiding this comment.
If these are now only used for the fallback impl, they should be moved to intrinsics/fallback.
There was a problem hiding this comment.
Is this test doing anything useful? We already have the other test ensuring that the LLVM intrinsic gets generated.
| /// This corresponds to `@llvm.pext.*`. | ||
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| #[unstable(feature = "uint_gather_scatter_bits", issue = "149069")] |
There was a problem hiding this comment.
Intrinsic will not be stabilized so they should not have a separate feature gate.
|
Reminder, once the PR becomes ready for a review, use |
Did you confirm that they produce good codegen, esp. on LLVM 23? For the case where they get expanded, that is. |
I don't know what you mean by that. |
|
When there is no native instruction |
|
Which architectures would that affect? |
|
You'd want to look at something like x86 without bmi2. Just trying the 32-bit case, we have current Rust codegen: https://rust.godbolt.org/z/4snnWPhKP And the LLVM intrinsic expansion: https://llvm.godbolt.org/z/bx6TKW6hf It looks like Rust's current fallback produces less instructions, it's ~180 total vs ~250 total. Doesn't look like this changes substantially in LLVM 24 either. |
|
So... this PR is a regression for such targets? Any suggestions for what to do? We could in principle gate the use of the intrinsic on target & target features, and use the fallback body otherwise, just like it is already used on older LLVM. |
|
It looks like there is an LLVM PR to improve the expansion: llvm/llvm-project#227292 I'd probably just wait until that gets in. |
8d64e63 to
935f428
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. |
|
@rustbot ready |
|
Error: Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip. |
This comment has been minimized.
This comment has been minimized.
935f428 to
3ead23f
Compare
There was a problem hiding this comment.
This LGTM from the compiler implementation side, but I cannot comment on when we should actually start using the attribute wrt LLVM support.
r? @nikic
| let pair = self.insert_value(pair, high, 1); | ||
| pair | ||
| } | ||
| // FIXME(llvm): These intrinsics were introduced in LLVM 23. |
There was a problem hiding this comment.
| // FIXME(llvm): These intrinsics were introduced in LLVM 23. | |
| // Checking LLVM version as these intrinsics were introduced in LLVM 23. |
| #[unstable(feature = "core_intrinsics", issue = "none")] | ||
| #[rustc_const_unstable(feature = "core_intrinsics", issue = "none")] |
There was a problem hiding this comment.
You don't need #[unstable] here, the const attribute is enough.
|
r? @nikic |
|
Requested reviewer is already assigned to this pull request. Please choose another assignee. |
3ead23f to
375326e
Compare
|
Updated. Thank you for you review :D |
|
☔ The latest upstream changes (presumably #165760) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
View all comments
Tracking issue: #149069
LLVM 23 introduced generic intrinsics for pext (extract_bits) and pdep (deposit_bits)