Don't compute FnAbi for LLVM intrinsics - #160077
Conversation
|
Some changes occurred to the CTFE machinery These commits modify compiler targets. Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
|
|
|
I guess this finishes my quest of getting rid of
There is still cleanup that can be done, but at least this wildly wrong combination is gone. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| func: OpTy<'tcx, M::Provenance>, | ||
| callee: FnVal<'tcx, M::ExtraFnVal>, |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This comment has been minimized.
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>); |
There was a problem hiding this comment.
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] }.
7358ce7 to
eacedff
Compare
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