Changes in atomic_rmw_op.rs

9ec02f9d - Decouple `serde` from its `derive` crate (#6917)

Tue, 29 Aug 2023 16:02:06 +0000

Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/atomic_rmw_op.rs

fc080c73 - fuzzgen: Add `AtomicRMW` (#5861)

Thu, 23 Feb 2023 18:34:28 +0000

fuzzgen: Add `AtomicRMW` (#5861) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/atomic_rmw_op.rs

ff22842d - More atomic ops

Sun, 14 Feb 2021 10:42:28 +0000

More atomic ops List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/atomic_rmw_op.rs

25e31739 - Implement Wasm Atomics for Cranelift/newBE/aarch64.

Wed, 29 Jul 2020 09:05:39 +0000

Implement Wasm Atomics for Cranelift/newBE/aarch64.The implementation is pretty straightforward. Wasm atomic instructions fallinto 5 groups* atomic read-modify-write* atomic compare-and-swap* atomic loads* atomic stores* fencesand the implementation mirrors that structure, at both the CLIF and AArch64levels.At the CLIF level, there are five new instructions, one for each group. Somecomments about these:* for those that take addresses (all except fences), the address is contained entirely in a single `Value`; there is no offset field as there is with normal loads and stores. Wasm atomics require alignment checks, and removing the offset makes implementation of those checks a bit simpler.* atomic loads and stores get their own instructions, rather than reusing the existing load and store instructions, for two reasons: - per above comment, makes alignment checking simpler - reuse of existing loads and stores would require extension of `MemFlags` to indicate atomicity, which sounds semantically unclean. For example, then *any* instruction carrying `MemFlags` could be marked as atomic, even in cases where it is meaningless or ambiguous.* I tried to specify, in comments, the behaviour of these instructions as tightly as I could. Unfortunately there is no way (per my limited CLIF knowledge) to enforce the constraint that they may only be used on I8, I16, I32 and I64 types, and in particular not on floating point or vector types.The translation from Wasm to CLIF, in `code_translator.rs` is unremarkable.At the AArch64 level, there are also five new instructions, one for eachgroup. All of them except `::Fence` contain multiple real machineinstructions. Atomic r-m-w and atomic c-a-s are emitted as the usualload-linked store-conditional loops, guarded at both ends by memory fences.Atomic loads and stores are emitted as a load preceded by a fence, and a storefollowed by a fence, respectively. The amount of fencing may be overkill, butit reflects exactly what the SM Wasm baseline compiler for AArch64 does.One reason to implement r-m-w and c-a-s as a single insn which is expandedonly at emission time is that we must be very careful what instructions weallow in between the load-linked and store-conditional. In particular, wecannot allow *any* extra memory transactions in there, since -- particularlyon low-end hardware -- that might cause the transaction to fail, hencedeadlocking the generated code. That implies that we can't present the LL/SCloop to the register allocator as its constituent instructions, since it mightinsert spills anywhere. Hence we must present it as a single indivisibleunit, as we do here. It also has the benefit of reducing the total amount ofwork the RA has to do.The only other notable feature of the r-m-w and c-a-s translations intoAArch64 code, is that they both need a scratch register internally. Ratherthan faking one up by claiming, in `get_regs` that it modifies an extrascratch register, and having to have a dummy initialisation of it, these newinstructions (`::LLSC` and `::CAS`) simply use fixed registers in the rangex24-x28. We rely on the RA's ability to coalesce V<-->R copies to make thecost of the resulting extra copies zero or almost zero. x24-x28 are chosen soas to be call-clobbered, hence their use is less likely to interfere with longlive ranges that span calls.One subtlety regarding the use of completely fixed input and output registersis that we must be careful how the surrounding copy from/to of the arg/resultregisters is done. In particular, it is not safe to simply emit copies insome arbitrary order if one of the arg registers is a real reg. For thatreason, the arguments are first moved into virtual regs if they are notalready there, using a new method `::ensure_in_vreg`.Again, we rely on coalescing to turn them into no-ops in the common case.There is also a ridealong fix for the AArch64 lowering case for`Opcode::Trapif | Opcode::Trapff`, which removes a bug in which two trap insnsin a row were generated.In the patch as submitted there are 6 "FIXME JRS" comments, which mark thingswhich I believe to be correct, but for which I would appreciate a secondopinion. Unless otherwise directed, I will remove them for the final commitbut leave the associated code/comments unchanged. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/atomic_rmw_op.rs