Don't special-case llvm.* as nounwind

[purplesyringa]

Certain LLVM intrinsics, such as llvm.wasm.throw, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out catch_unwind under inlining or when llvm.wasm.throw is used directly by user code.

The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as extern "C" or other non-unwinding ABIs, so we won't codegen invoke for them anyway.

Closes #132416.

@rustbot label +T-compiler +A-panic

[rustbot]

r? @SparrowLii

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

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

[purplesyringa]

I'm not 100% sure there's no subtle issue here, even though throw seems to be the only intrinsic declared with extern "C-unwind" that I could find, so I'm obviously waiting on PR CI here.

[SparrowLii]

r? @workingjubilee :)

[rustbot]

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

[nikic]

This looks reasonable to me.

The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as extern "C" or other non-unwinding ABIs, so we won't codegen invoke for them anyway.

LLVM intrinsics should generally use the "unadjusted" ABI. It looks like we don't have "unadjusted-unwind", but I guess it can be added when needed...

[bors]

☔ The latest upstream changes (presumably #144249) made this pull request unmergeable. Please resolve the merge conflicts.

[nikic]

@bors r+

[bors]

📌 Commit ed11a39 has been approved by nikic

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
looks like this failed here #144428 (comment)

[rustbot]

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

[purplesyringa]

That's fun... looks like the lint was always meant to trigger on that code but only started doing it now due to this bug.

@rustbot ready

[nikic]

I'm not sure I fully understand the implications of suppressing the lint. The docs say:

For crates containing such calls, if they are compiled with -C panic=unwind then the produced library cannot be linked with crates compiled with -C panic=abort. For crates that desire this ability it is therefore necessary to avoid such calls.

[purplesyringa]

I agree that it's strange and suppressing the lint doesn't strike me as right either. I had assumed that since core worked just fine with the lint effectively broken, that was a proof that the approach works. But you're right, I'll need to test this more

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[purplesyringa]

#118168 has this unresolved question:

Should exception-handling instructions (e.g. from prebuilt libstd) be stripped out if panic=abort? If so, by whom? wasm-ld? wasm-opt does currently implement a --strip-eh pass; maybe that's good enough if users want to target wasm MVP?

And there's this snippet in unwind:

rust/library/unwind/src/wasm.rs

Lines 48 to 63 in a955f1c

	cfg_if::cfg_if! {
	// panic=abort is default for wasm targets. Because an unknown instruction is a load-time
	// error on wasm, instead of a runtime error like on traditional architectures, we never
	// want to codegen a `throw` instruction, as that would break users using runtimes that
	// don't yet support exceptions. The only time this first branch would be selected is if
	// the user explicitly opts in to wasm exceptions, via -Zbuild-std with -Cpanic=unwind.
	if #[cfg(panic = "unwind")] {
	// corresponds with llvm::WebAssembly::Tag::CPP_EXCEPTION
	// in llvm-project/llvm/include/llvm/CodeGen/WasmEHFuncInfo.h
	const CPP_EXCEPTION_TAG: i32 = 0;
	core::arch::wasm::throw::<CPP_EXCEPTION_TAG>(exception.cast())
	} else {
	let _ = exception;
	core::arch::wasm::unreachable()
	}
	}

So I think the idea here is that if std is compiled with -C panic=unwind, it cannot currently be linked to -C panic=abort crates on Wasm because we don't have infrastructure to fix that, and that's the reason why we serve pre-compile std with -C panic=abort on Wasm targets. So the lint hits at a real problem, but it's not a new problem, and we're tracking it elsewhere anyway.

I've added a FIXME comment, but otherwise this PR can be merged, I think. I've verified that it doesn't break -C panic=abort std builds.

cc @coolreader18

@rustbot ready

[nikic]

@bors2 try jobs=dist-various-1

[rust-bors]

⌛ Trying commit 17519ae with merge 5319385…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 5319385 (53193856e5a4ac7cbbe00ed3c7f71acb23e65133, parent: 8708f3cd1f96d226f6420a58ebdd61aa0bc08b0a)

[nikic]

@bors r+

[bors]

📌 Commit 17519ae has been approved by nikic

It is now in the queue for this repository.

[bors]

⌛ Testing commit 17519ae with merge 2b5e239...

[bors]

☀️ Test successful - checks-actions
Approved by: nikic
Pushing 2b5e239 to master...

[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 f8e355c (parent) -> 2b5e239 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 2b5e239c6b86cde974b0ef0f8e23754fb08ff3c5 --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. x86_64-apple-2: 4780.3s -> 3601.6s (-24.7%)
2. dist-aarch64-linux: 8092.6s -> 6146.0s (-24.1%)
3. x86_64-apple-1: 9031.8s -> 6913.5s (-23.5%)
4. pr-check-2: 2532.3s -> 2142.6s (-15.4%)
5. dist-aarch64-apple: 5493.3s -> 6107.6s (11.2%)
6. x86_64-rust-for-linux: 2919.0s -> 2599.7s (-10.9%)
7. pr-check-1: 1715.5s -> 1535.6s (-10.5%)
8. x86_64-gnu-llvm-19: 2772.9s -> 2498.1s (-9.9%)
9. aarch64-apple: 5258.1s -> 5753.1s (9.4%)
10. i686-gnu-2: 5931.5s -> 5374.0s (-9.4%)

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 (2b5e239): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary 4.5%, secondary 2.8%)

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

	mean	range	count
Regressions ❌ (primary)	4.5%	[4.4%, 4.7%]	2
Regressions ❌ (secondary)	2.8%	[1.1%, 5.2%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.5%	[4.4%, 4.7%]	2

Cycles

Results (primary 2.0%)

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

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

Binary size

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

Bootstrap: 465.942s -> 467.432s (0.32%)
Artifact size: 376.74 MiB -> 376.83 MiB (0.02%)