Skip to content

Don't compute FnAbi for LLVM intrinsics - #160077

Open
bjorn3 wants to merge 6 commits into
rust-lang:mainfrom
bjorn3:no_unadjusted_fn_abi
Open

Don't compute FnAbi for LLVM intrinsics#160077
bjorn3 wants to merge 6 commits into
rust-lang:mainfrom
bjorn3:no_unadjusted_fn_abi

Conversation

@bjorn3

@bjorn3 bjorn3 commented Jul 28, 2026

Copy link
Copy Markdown
Member

They don't have a sensible FnAbi, so the fact that we still compute an FnAbi for them requires us to make the ABI sanity check more lenient than it should be.

r? @RalfJung as all non-trivial changes are in Miri

@rustbot

rustbot commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

@rustbot rustbot added 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. labels Jul 28, 2026
@rustbot

rustbot commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Comment on lines +26 to 27
func: OpTy<'tcx, M::Provenance>,
callee: FnVal<'tcx, M::ExtraFnVal>,

@RalfJung RalfJung Jul 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This introduces redundancy (func and callee conceptually contain the same data). So I am not a fan of this.

What's the rationale for these non-trivial interpreter changes? I would understand making the fn_abi field an Option for calls that don't need an ABI, but this goes much beyond that it seems, by entirely removing fn_abi (and fn_sig).

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I could replace the func field with just the Ty. Making fn_abi optional would mean I did have to match on the instance inside eval_callee_and_args and do an unwrap outside of it. I can do it if you prefer it that way.

@RalfJung RalfJung Jul 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I could replace the func field with just the Ty

That would be better, albeit still a bit odd.

Making fn_abi optional would mean I did have to match on the instance inside eval_callee_and_args and do an unwrap outside of it. I can do it if you prefer it that way.

Well I don't even know yet why you need to change all those other things. I could reverse engineer it from your PR but it'd be easier if you just explained it to me.

@rust-log-analyzer

This comment has been minimized.

fn test_f32x2(a: f32x2);
fn test_f32x2_arr(a: f32x2);
fn test_simd(a: Simd<i32, 4>);
fn test_simd_unaligned(a: Simd<i32, 3>);

@bjorn3 bjorn3 Jul 29, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

There is no way to test this specific case anymore it seems. LLVM doesn't accept PackedSimd on intrinsics, extern "unadjusted" requires LLVM intrinsics and any other ABI doesn't pass non-power-of-2 vectors as { [3 x i32] }.

View changes since the review

@bjorn3
bjorn3 force-pushed the no_unadjusted_fn_abi branch from 7358ce7 to eacedff Compare July 29, 2026 10:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants