Avoid a bitcast FFI call in transmuting

[scottmcm]

For things that only change the valid ranges, we can just return the input, rather than making the LLVMBuildBitCast call and having it then do nothing.

I tried to tweak this a bit more and broke stuff, so I also added some extra tests for that as we apparently didn't have coverage.

[rustbot]

r? @WaffleLapkin

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

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[WaffleLapkin]

@bors r+ rollup

[WaffleLapkin]

did not mean to clone PR...
@bors r+ rollup

[bors]

📌 Commit 5d16a7b has been approved by WaffleLapkin

It is now in the queue for this repository.

[scottmcm]

Huh, I wasn't expecting anything material from this, but something in #142997 was, so out of curiosity
@rust-timer build 4e95f4a

[rust-timer]

Finished benchmarking commit (4e95f4a): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.4%	[-1.4%, -1.4%]	1
Improvements ✅ (secondary)	-1.4%	[-1.4%, -1.4%]	1
All ❌✅ (primary)	-1.4%	[-1.4%, -1.4%]	1

Max RSS (memory usage)

Results (primary -1.3%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.0%	[4.2%, 7.8%]	2
Improvements ✅ (primary)	-1.3%	[-1.3%, -1.3%]	1
Improvements ✅ (secondary)	-4.1%	[-7.6%, -2.5%]	5
All ❌✅ (primary)	-1.3%	[-1.3%, -1.3%]	1

Cycles

Results (secondary -5.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.0%	[-5.1%, -4.8%]	3
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 689.044s -> 689.011s (-0.00%)
Artifact size: 372.03 MiB -> 372.01 MiB (-0.00%)

[sayantn]

Idk how, but this is creating miscompilations when casting from T to Tx1 (single-element vector), causing stdarch CI to fail

Which brings up the question, are these transmutes even valid? Because they are used quite a bit in stdarch (mainly in ARM, which has 1-element SIMD types)

[folkertdev]

I believe that this change is incorrect. We can't just implicitly convert between types that have the same scalar representation, but a different backend type. For instance

https://godbolt.org/z/PaaGWTv5a

#![feature(repr_simd)]

#[repr(simd)]
#[derive(Clone, Copy)]
struct S([i64; 1]);

#[no_mangle]
pub extern "C" fn single_element_simd(b: S) -> i64 {
    unsafe { std::mem::transmute(b) }
}

generates broken IR:

define noundef i64 @single_element_simd(<1 x i64> %b) unnamed_addr {
start:
  ret <1 x i64> %b
}

[RalfJung]

It's very strange that a function that is supposed to work on all "immediates" just takes abi::Scalar. That doesn't fully describe an immediate. Either the function should be renamed to transmute_scalar (and never be called for non-scalar types), or it should take the full BackendRepr so that it has a clue what the two immediates are.