tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: New test

[Enselic]

Closes#60044 which has one 👍 and one ❤️ vote and just E-needs-test.

[rustbot]

r? @Mark-Simulacrum

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

[clubby789]

I think this should be a codegen-llvm test as it's not backend-specific

[Enselic]

Good call. That deserves consideration.

Here is what the correct LLVM IR currently looks like:

; Function Attrs: mustprogress nofree norecurse nounwind nonlazybind willreturn memory(readwrite, argmem: none, inaccessiblemem: write)define noundef range(i641, 0) i64@some_non_zero_from_atomic_get() unnamed_addr #0 {
start:
%0 = loadatomici64, ptr@_ZN38some_non_zero_from_atomic_optimization1X17h41fcdb7c72ef9763Emonotonic, align8%1 = icmpnei64%0, 0tailcallvoid@llvm.assume(i1%1)
reti64%0
}

Full LLVM IR

; ModuleID = 'some_non_zero_from_atomic_optimization.ca4055969c8517ab-cgu.0'
source_filename = "some_non_zero_from_atomic_optimization.ca4055969c8517ab-cgu.0"targetdatalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"targettriple = "x86_64-unknown-linux-gnu"@_ZN38some_non_zero_from_atomic_optimization1X17h41fcdb7c72ef9763E = local_unnamed_addrglobal [8 x i8] c"\07\00\00\00\00\00\00\00", align8@some_non_zero_from_atomic_get2 = unnamed_addraliasi64 (), ptr@some_non_zero_from_atomic_get; Function Attrs: mustprogress nofree norecurse nounwind nonlazybind willreturn memory(readwrite, argmem: none, inaccessiblemem: write)define noundef range(i641, 0) i64@some_non_zero_from_atomic_get() unnamed_addr #0 {
start:
%0 = loadatomici64, ptr@_ZN38some_non_zero_from_atomic_optimization1X17h41fcdb7c72ef9763Emonotonic, align8%1 = icmpnei64%0, 0tailcallvoid@llvm.assume(i1%1)
reti64%0
}
; Function Attrs: mustprogress nocallback nofree nosync nounwind willreturn memory(inaccessiblemem: write)declarevoid@llvm.assume(i1 noundef) #1attributes #0 = { mustprogress nofree norecursenounwindnonlazybind willreturn memory(readwrite, argmem: none, inaccessiblemem: write) "probe-stack"="inline-asm""target-cpu"="x86-64" }
attributes #1 = { mustprogress nocallback nofree nosync nounwind willreturn memory(inaccessiblemem: write) }
!llvm.module.flags = !{!0, !1}
!llvm.ident = !{!2}
!0 = !{i328, !"PIC Level", i322}
!1 = !{i322, !"RtLibUseGOT", i321}
!2 = !{!"rustc version 1.91.1 (ed61e7d7e 2025-11-07)"}

As you can see, the LLVM IR is considerably more elaborate and is likely to change over time as we adjust codegen and adapt to new LLVM versions. So an LLVM IR version of this test risks becoming a maintenance burden that will steal time from doing other improvements.

Besides, it does not seem impossible that this optimization could regress on the LLVM side, which an LLVM IR based test would not catch.

So my recommendation is to go ahead with this test, because it tests what actually matters (the end result) and that is unlikely to ever change.

That said, I can certainly turn this into an LLVM test if that is considered mandatory for merge. We can wait and see see what others think perhaps.

[Mark-Simulacrum]

@bors r+

I don't think it has to check the LLVM IR necessarily.

[bors]

📌 Commit faf06cc has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[JonathanBrouwer]

@bors r- #150220 (comment)

[clubby789]

.set some_non_zero_from_atomic_get2, some_non_zero_from_atomic_get 

vs

// CHECK-DAG: some_non_zero_from_atomic_get2 = some_non_zero_from_atomic_get

[JonathanBrouwer]

@bors try jobs=x86_64-gnu-llvm-20-3

[rust-bors]

☀️ Try build successful (CI)
Build commit: 7367c05 (7367c0569c59e5379c39bfd46bd6431b7b0eb4c6, parent: acfd264f4df23b15cf27a15a85f76ed61977b48a)

[nikic]

As you can see, the LLVM IR is considerably more elaborate and is likely to change over time as we adjust codegen and adapt to new LLVM versions. So an LLVM IR version of this test risks becoming a maintenance burden that will steal time from doing other improvements.

As you are currently finding out, the reason we test codegen instead of assembly is that assembly tests are even more fragile :)

For cases like this, you don't really need to check the exact emitted IR, something like CHECK-NOT: panic (often combined with CHECK-NOT: unreachable) tends to be good enough.

You can use -Zmerge-functions=disabled to avoid function merging, which tends to make writing tests more inconvenient.

[Enselic]

Ok I have now been convinced that we should use an LLVM IR test instead :)

I am not relaxed enough with FileCheck to be comfortable with some CHECK-NOT: unreachable checks and the like, so I went for detailed checks instead. That way I feel confident we will not regress. But I'm of course more than willing to keep adjusting until everyone is happy with how it looks.

[Enselic]

@rustbot ready

[Mark-Simulacrum]

I think we can simplify the tests and make them less brittle while doing so.

View changes since this review

[Enselic]

Thanks for the feedback. I have now turned this into a "not panic" and "not unreachable" test and made sure that it will catch a regression.

The test fails with nightly-2024-02-08:

$ rustc +nightly-2024-02-08 --emit=llvm-ir -O -Zmerge-functions=disabled \ tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs && \/usr/lib/llvm-20/bin/FileCheck \ tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs \ <some-non-zero-from-atomic-optimization.lltests/codegen-llvm/some-non-zero-from-atomic-optimization.rs:76:15: error: CHECK-NOT: excluded string found in input// CHECK-NOT: panic ^<stdin>:26:14: note: found here; call core::panicking::panic ^~~~~tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs:77:15: error: CHECK-NOT: excluded string found in input// CHECK-NOT: unreachable ^<stdin>:28:2: note: found here unreachable ^~~~~~~~~~~

but passes with nightly-2024-02-09:

$ rustc +nightly-2024-02-09 --emit=llvm-ir -O -Zmerge-functions=disabled \ tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs && \/usr/lib/llvm-20/bin/FileCheck \ tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs \ <some-non-zero-from-atomic-optimization.ll && \echo passpass

As you can see above I did a bisect and it was fixed in nightly-2024-02-09. Here is the set of candidate commits that fixed it. See #60044 (comment) for a guess on which one it was.

git log ^8ace7ea1f7cbba7b4f031e66c54ca237a0d65de6 98aa362 --no-merges --oneline

ad511ef Avoid ICE in drop recursion check in case of invalid drop impls
5cb9e31 Add release note for new ambiguous_wide_pointer_comparisons lint
7dc182d Fix mir pass ICE in the presence of other errors
6af2d3c Fix span_bug! backtraces
f867742 reviews + rebase
b181a12 rename instantiate_binder_with_placeholders
ac559af introduce enter_forall
da4ec6f Deduplicate tcx.instance_mir(instance) calls in try_instance_mir
4733b1b Test min_exhaustive_patterns in more cases
30793ca Match min_exhaustive_patterns implementation with exhaustive_patterns
f676c3d Remove myself from review rotation.
0ce71f6 make future diffs minimal
eab2adb Continue to borrowck even if there were previous errors
e5461de Taint borrowck results without running any borrowck if the MIR body was already tainted
1fcd04e inline a function that is only used in clippy
8a5847f Already poison the type_of result of the anon const used in the typeof expression
6b175a8 Add SubdiagnosticMessageOp as a trait alias.
9dca6be Prefer "0..MAX not covered" to "_ not covered"
970f46c Add tests
c636c7a address review comments and add more tests
cd21b1d No need to take ImplTraitContext by ref
18e5bbf improve pretty printing for trait objects
4229875 Update test output.
5d65418 Replace transmute_copy with ptr::read.
af48cf6 Don't use assert_unsafe_precondition twice.
fd92021 add test for pretty printing trait objects
a67b72c Make NonZero constructors generic.
58d70d6 Simplify impl_zeroable_primitive macro.
0a50dba docs: also check the inline stmt during redundant link check
3e8c8d8 hir: Add some FIXMEs for future work
a61019b hir: Remove fn opt_hir_id and fn opt_span
363b098 hir: Make sure all HirIds have corresponding HIR Nodes
a2ab48c resolve: Unload speculatively resolved crates before freezing cstore
6fbd761 Also turn moves into copies even if through projections.
c151ed4 Add test.
1a3214b Make sure refinement still works
e65abc0 Make the error message better
16cbdd0 Allow desugaring async fn in trait to compatible, concrete future types
a59a1e7 Remove some invalid cfg(doc) code
83738a9 Stop bailing out from compilation just because there were incoherent traits
7f1d523 Avoid emitting trait bound errors of incoherent traits
0211221 Prevent running some code if it is already in the map
74dbf3a fix ui tests
96108c5 make effect infer variables suggestable in diagnostics
c9192be Reconstify Add
6b2a824 Remove dead args from functions
0825ad3 Clarify the new binding dance
09d4613 Put new bindings first in refutable cases too
e902878 Clarify the binding dance
96ff1a4 Move Or test out of the loop
3ea464f Add tests

@rustbot ready

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 55833a9 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 55833a9 with merge 5497a36...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 5497a36 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 8a24a20 (parent) -> 5497a36 (this PR)

Test differences

Show 6 test diffs

Stage 1

• [codegen] tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: [missing] -> pass (J1)
• [codegen] tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: [missing] -> ignore (only executed when the pointer width is 64bit) (J2)

Stage 2

• [codegen] tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: [missing] -> pass (J0)
• [codegen] tests/codegen-llvm/some-non-zero-from-atomic-optimization.rs: [missing] -> ignore (only executed when the pointer width is 64bit) (J3)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-20-1, aarch64-msvc-1, test-various, x86_64-gnu, x86_64-gnu-llvm-20-2, x86_64-gnu-llvm-21-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-20-3, x86_64-gnu-llvm-21-3
• J2: pr-check-2
• J3: arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 5497a36a7faf3d2af37beebcff7008e493202902 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-aarch64-apple: 9354.3s -> 7725.4s (-17.4%)
2. dist-sparcv9-solaris: 5844.7s -> 5071.0s (-13.2%)
3. dist-x86_64-apple: 8684.9s -> 9695.9s (+11.6%)
4. x86_64-gnu-llvm-20-1: 3789.7s -> 4222.8s (+11.4%)
5. test-various: 6795.0s -> 7495.4s (+10.3%)
6. aarch64-msvc-2: 6840.8s -> 6192.8s (-9.5%)
7. x86_64-gnu-debug: 6894.7s -> 6243.6s (-9.4%)
8. dist-x86_64-solaris: 5960.6s -> 5405.2s (-9.3%)
9. aarch64-gnu-llvm-20-2: 2901.7s -> 2656.9s (-8.4%)
10. x86_64-gnu-nopt: 7952.2s -> 8588.1s (+8.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (5497a36): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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.4%	[0.4%, 0.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (secondary 4.3%)

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)	4.3%	[4.3%, 4.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 473.485s -> 471.287s (-0.46%)
Artifact size: 390.77 MiB -> 390.83 MiB (0.02%)