Skip to content

Conversation

sayantn
Copy link
Contributor

@sayantn sayantn commented Aug 20, 2025

Parent: #145686
ACP: rust-lang/libs-team#642

This implements funnel shifts on primitive integer types. Implements this for cg_llvm, with a fallback impl for everything else

Thanks @folkertdev for the fixes and tests

cc @rust-lang/libs-api

@rustbot
Copy link
Collaborator

rustbot commented Aug 20, 2025

r? @tgross35

rustbot has assigned @tgross35.
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

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 20, 2025
@rustbot
Copy link
Collaborator

rustbot commented Aug 20, 2025

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

@rust-log-analyzer

This comment has been minimized.

@tgross35
Copy link
Contributor

I see there is a tracking issue, but not an ACP for this. Could you create one? It's an issue template at https://github.com/rust-lang/libs-team/issues.

@rustbot
Copy link
Collaborator

rustbot commented Aug 22, 2025

This PR was rebased onto a different master 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.

@rust-log-analyzer

This comment has been minimized.

@sayantn sayantn force-pushed the integer-funnel-shift branch from b91850b to 400a29d Compare August 22, 2025 16:30
@rust-log-analyzer

This comment has been minimized.

@sayantn sayantn force-pushed the integer-funnel-shift branch from 400a29d to 23601d2 Compare August 22, 2025 16:37
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Aug 24, 2025

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

@rust-log-analyzer

This comment has been minimized.

@tgross35 tgross35 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@sayantn sayantn force-pushed the integer-funnel-shift branch from 5f4c412 to 63fde15 Compare August 28, 2025 01:39
@rust-log-analyzer

This comment has been minimized.

@sayantn
Copy link
Contributor Author

sayantn commented Aug 28, 2025

@bjorn3 could you look into this ICE? The clif code looks fine enough, and I don't have enough expertise on clif to see what's going wrong.

@bjorn3
Copy link
Member

bjorn3 commented Aug 28, 2025

At the very least there is a bug in the Cranelift IR verifier causing it to panic at https://github.com/bytecodealliance/wasmtime/blob/ecda6e330a946821b5edc0a90bd62288cf7df943/cranelift/codegen/src/verifier/mod.rs#L1907

But the thing you are doing wrong is let zero = fx.bcx.ins().iconst(ty, 0); I think, which is not valid if ty is an i128. You can use the type_zero_value helper function from the common module instead.

Edit: I'm not sure how that even passed the typecheck pass of the verifier.

@sayantn sayantn force-pushed the integer-funnel-shift branch from 63fde15 to 3d0b3fb Compare August 28, 2025 22:58
@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you update the tracking issue to have signatures matching rust-lang/libs-team#642 (comment)? This should match then.

Copy link
Contributor Author

@sayantn sayantn Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 👍🏽, could you check if it makes sense (I'm bad at writing docs etc)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's easier than that: tracking issues should show function signatures in something like an impl uX { ... } block, no need to write docs :)

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 28, 2025
@sayantn sayantn force-pushed the integer-funnel-shift branch from 3d0b3fb to d1f3861 Compare August 30, 2025 00:38
@sayantn
Copy link
Contributor Author

sayantn commented Aug 30, 2025

Should I add more variants of the functions? (e.g. wrapping, overflowing, checked, unchecked etc, the default one is the traditionally strict variant)

@tgross35
Copy link
Contributor

I don't think there is any need in the initial PR here. They can be added as a followup

@clarfonthey
Copy link
Contributor

Also worth mentioning that the hardest part here is getting the intrinsic and actual functionality working, since all the other variants, at least for shifts, just require a few explicit checks.

@sayantn
Copy link
Contributor Author

sayantn commented Aug 30, 2025

In that case, I guess this PR is ready. @rustbot ready

@rustbot rustbot added S-waiting-on-review 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 Aug 30, 2025
#[rustc_nounwind]
#[rustc_const_unstable(feature = "funnel_shifts", issue = "145686")]
#[unstable(feature = "funnel_shifts", issue = "145686")]
#[miri::intrinsic_fallback_is_spec]
Copy link
Member

@RalfJung RalfJung Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This attribute means the fallback implementation must check the size to be valid and do unreachable_unchecked (or equivalent) in that case.

Please add Miri tests to ensure this works correctly: all cases of UB must be detected.

Copy link
Member

@RalfJung RalfJung Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the implementation, I don't think you are checking for UB here. Seems like unchecked_funnel_shl(0, 0, n) will just work for any n.

Please don't just blindly add attributes like this, make sure you understand them or ask what to do. Adding this attribute incorrectly introduces hard-to-find bugs into the very tools unsafe code authors trust to find bugs for them.

EDIT: Or, are you relying on the checks in unchecked_shr/unchecked_shl? That's super subtle, definitely needs a comment at least.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also clarifying a bit: since the fallbacks work a bit differently than you'd expect, this kind of info should probably be listed in the SAFETY comment a few lines below. Something like "UB-checking is done inside the called method" and then adding more explicit comments inside the trait implementations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not actually testing for UB here, I misunderstood what the attribute means. Should I add such UB checks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added some assume calls. @RalfJung could you check if it's ok?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be fair, I don't think that relying on the attribute missing is reasonable, since you can easily just copy intrinsic bodies here. It makes a lot more sense to just have a triage bot reply to any PR that includes the attribute to make sure people get notified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both you personally and miri as a group were pinged in various ways in #145690 (comment). Then the implementation evolved somewhat but it seems reasonable to assume that this PR already had your attention?

If not, should we add a ping rule for that attribute specifically?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should be a ping rule for the attribute just to be safe, since there appears to be a desire to ping the miri group whenever it's used.

Copy link
Member

@RalfJung RalfJung Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have support for "ping on specific text", see rust-lang/triagebot#1851. If we did have that then yes we'd definitely use it here.

To be fair, I don't think that relying on the attribute missing is reasonable, since you can easily just copy intrinsic bodies here.

I don't think it is reasonable to copy an attribute you don't understand, and then just hope it works out. I expect contributors to flag things like this explicitly in the PR so it can be discussed.

We could rename the attribute to make it sound more scary, but it's not clear to me that that would help. It's also hard to find a reasonably concise name that captures every aspect of this attribute.

Both you personally and miri as a group were pinged in various ways

That's true, I forgot miri already got pinged because the intrinsic file changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is reasonable to copy an attribute you don't understand, and then just hope it works out.

I agree, it was a mistake on my part. I didn't think it through, and just copied the similar implementations of intrinsics, partly due to my inexperience in implementing rust-intrinsics. Anyway, thanks you all for all the help in pointing out this mistake

sayantn and others added 3 commits September 2, 2025 06:38
 - Add a fallback implementation for the intrinsics

Co-Authored-By: folkertdev <folkert@folkertdev.nl>
Co-Authored-By: folkertdev <folkert@folkertdev.nl>
@sayantn sayantn force-pushed the integer-funnel-shift branch from d1f3861 to c9bab92 Compare September 2, 2025 01:12
@rustbot
Copy link
Collaborator

rustbot commented Sep 2, 2025

The Miri subtree was changed

cc @rust-lang/miri

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Miri checks look good apart from a small nit, thanks!

View changes since this review

#[cfg_attr(miri, track_caller)]
#[inline]
unsafe fn unchecked_funnel_shl(self, rhs: Self, shift: u32) -> Self {
// SAFETY: this is guaranteed by the caller
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// SAFETY: this is guaranteed by the caller
// This implementation is also used by Miri so we have to check the precondition.
// SAFETY: this is guaranteed by the caller

(same in unchecked_funnel_shr)

Comment on lines +5 to +6
std::intrinsics::unchecked_funnel_shl(1_u32, 2, 5);
std::intrinsics::unchecked_funnel_shl(1_u32, 2, 31);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this, please add calls in src/tools/miri/tests/pass/intrinsics/integer.rs that check the result.

(Same for funnel_shr)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are already testing the const-eval implementation in library/coretests/tests/num/uint_macros.rs, do I need to add these tests too?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, fair. But then what's the point of these non-failing calls here?

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. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants