Don't enable shared memory by default with Wasm atomics

[daxpedda]

This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it.

Context

Currently the atomics target features is unstable and can't be used without re-building Std with it (-Zbuild-std).
Enabling the atomics target feature automatically enables shared memory.
Shared memory is required to actually allow multi-threading.
However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs.
So it is very undesirable to enable shared memory by default for the majority of users.

While it is possible to use atomics without shared memory, the question remains what use-case this scenario has.
The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (#136382).

So alternatively, we might consider not enabling atomics by default even when LLVM does. In which case everything would remain the same.

---

This will break current Web multi-threading users. To address this they can add the following RUSTFLAGS:

-Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base

We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only threads target feature.

Addresses #77839.
r? @alexcrichton

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[alexcrichton]

Should the wasm32-wasip1-threads target specification perhaps get adjusted to pass these arguments by default? Otherwise that target won't actually produce a shared memory by default if I'm understanding this right. Otherwise though this looks reasonable to me, thanks!

[daxpedda]

AFAIK it already does:

rust/compiler/rustc_target/src/spec/targets/wasm32_wasip1_threads.rs

Lines 20 to 32 in 1e1a394

	options.add_pre_link_args(
	LinkerFlavor::WasmLld(Cc::No),
	&["--import-memory", "--export-memory", "--shared-memory"],
	);
	options.add_pre_link_args(
	LinkerFlavor::WasmLld(Cc::Yes),
	&[
	"--target=wasm32-wasip1-threads",
	"-Wl,--import-memory",
	"-Wl,--export-memory,",
	"-Wl,--shared-memory",
	],
	);

[bjorn3]

That is missing the --max-memory, which is mandatory for shared memories.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[daxpedda]

That is missing the --max-memory, which is mandatory for shared memories.

Its interesting that so many flags were overlapping then.
I added --max-memory to the affected targets.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 3e8ce2b has been approved by alexcrichton

It is now in the queue for this repository.

[RReverser]

Or like suggested before: a Rust-only threads target feature.

I think we should do this, yes - it's too many arguments for users to copy-paste in each project.

It should be purely additive though - if top-level crate enables it, that should be enough to pass these arguments to the linker even if standard library was built with just atomics - that way we'll be able to reuse same prebuilt standard library for single-threaded and true multi-threaded builds.