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