Codegen ZSTs without an allocation

[Mark-Simulacrum]

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in #67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since #63635.

[rustbot]

r? @lcnr

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

[Mark-Simulacrum]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 1266e22 with merge f266dba...

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

@bors try

[bors]

⌛ Trying commit 388646a with merge 0d984e9...

[bors]

☀️ Try build successful - checks-actions
Build commit: 0d984e9 (0d984e9cba0b38db05ce9ac01597ab4b04604840)

[rustbot]

Some changes occurred in run-make tests.

cc @jieyouxu

[rust-timer]

Finished benchmarking commit (0d984e9): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

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

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.5%	[-2.4%, -0.1%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.5%	[-2.4%, -0.1%]	3

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.3%, -0.0%]	61
Improvements ✅ (secondary)	-0.8%	[-2.3%, -0.0%]	16
All ❌✅ (primary)	-0.1%	[-0.3%, -0.0%]	61

Bootstrap: 677.239s -> 677.892s (0.10%)
Artifact size: 315.99 MiB -> 315.96 MiB (-0.01%)

[Mark-Simulacrum]

Rebased atop #123941, but otherwise this looks ready for review. Perf results indicate neutral runtime performance but a clear, though small, improvement in binary sizes.

[lcnr]

cc @RalfJung

This seems totally fine to me, I didn't try to understand the changes to the llvm wrapper yet 🤔 intend to look at it in-depth in a few days and then merge it unless there are any concerns

[Mark-Simulacrum]

Those changes will get squashed/rebased away (already approved in a separate PR).

IMO the fact that this found 1 case of UB and 1 broken test is actually pretty good justification for wanting to do it :)

[RalfJung]

Sorry, I'm not comfortable approving codegen PRs...
r? compiler

[oli-obk]

r? @oli-obk

@bors r+

[bors]

📌 Commit 9ab6e36 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9ab6e36 with merge 38104f3...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 38104f3 to master...

[rust-timer]

Finished benchmarking commit (38104f3): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.6%	[-3.3%, -0.1%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.6%	[-3.3%, -0.1%]	3

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.4%, -1.9%]	2
All ❌✅ (primary)	-	-	0

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.3%, -0.0%]	64
Improvements ✅ (secondary)	-0.7%	[-2.3%, -0.0%]	19
All ❌✅ (primary)	-0.1%	[-0.3%, -0.0%]	64

Bootstrap: 677.444s -> 677.262s (-0.03%)
Artifact size: 316.09 MiB -> 316.13 MiB (0.01%)

[alice-i-cecile]

FYI, this PR seems to have somehow broken Bevy's rendering with Rust 1.79, but only on Windows, and only with some hardware. Any tips on where to start debugging or resolving this would be appreciated.

[janhohenheim]

^ and only when using DX12 as a backend

[workingjubilee]

FYI, this PR seems to have somehow broken Bevy's rendering with Rust 1.79, but only on Windows, and only with some hardware. Any tips on where to start debugging or resolving this would be appreciated.

The issue is most likely that something was inappropriately relying on pointer equalities or inequalities that changed. Statics are not constants, but people slip up and address them as the same thing. Even if the Rust code itself doesn't do address equating, Rust coerces references to pointers, so often people directly pass a reference to a constant into FFI. Some DX12 code could have been happily reading some random uninit garbage and not really caring because it wasn't really using that read for anything important (i.e. "UB, but it had no significant effect in actual executions of a short-lived, very simple demo program"), but with this change, decided to deref a pointer into the zeroth page today, causing a segfault.

[workingjubilee]

( It is of course entirely plausible I am talking nonsense and it is a much more exotic problem or at least a more interesting bug, but I would first try to eliminate that case, which is why the curiosity about a backtrace in #126442 (comment) )