b81ef46c - Remove reference types (`r32` and `r64`) from Cranelift (#9164)

Thu, 22 Aug 2024 21:39:26 +0000

Remove reference types (`r32` and `r64`) from Cranelift (#9164)* Remove reference types (`r32` and `r64`) from Cranelift* restore fuzz regression test List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/user_stack_maps.rs

c0c3a68c - Cranelift: Remove the old stack maps implementation (#9159)

Wed, 21 Aug 2024 15:28:27 +0000

Cranelift: Remove the old stack maps implementation (#9159)They are superseded by the new user stack maps implementation. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/user_stack_maps.rs

b2025ead - Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)

Mon, 19 Aug 2024 00:18:25 +0000

Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)This moves Wasmtime over from the old, regalloc-based stack maps system to thenew "user" stack maps system.Removing the old regalloc-based stack maps system is left for follow-up work. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/user_stack_maps.rs

e20b4244 - Cranelift: Take user stack maps through lowering and emission (#8876)

Thu, 27 Jun 2024 18:40:54 +0000

Cranelift: Take user stack maps through lowering and emission (#8876)* Cranelift: Take user stack maps through lowering and emissionPreviously, user stack maps were inserted by the frontend and preserved in themid-end. This commit takes them from the mid-end CLIF into the backend vcode,and then from that vcode into the finalized mach buffer during emission.During lowering, we compile the `UserStackMapEntry`s into packed`UserStackMap`s. This is the appropriate moment in time to do that coalescing,packing, and compiling because the stack map entries are immutable from thispoint on.Additionally, we include user stack maps in the `Debug` and disassemblyimplementations for vcode, just after their associated safepointinstructions. This allows us to see the stack maps we are generating whendebugging, as well as write filetests that check we are generating the expectedstack maps for the correct instructions.Co-Authored-By: Trevor Elliott * uncomment debug assert that was commented out for debugging* Address review feedback* remove new method that was actually never needed---------Co-authored-by: Trevor Elliott List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/user_stack_maps.rs

59de3a32 - Cranelift: Allow CLIF frontends to define their own stack maps (#8728)

Fri, 07 Jun 2024 04:05:56 +0000

Cranelift: Allow CLIF frontends to define their own stack maps (#8728)Tracking GC references and producing stack maps is a significant amount ofcomplexity in `regalloc2`.At the same time, GC reference value types are pretty annoying to deal with inCranelift itself. We know our `r64` is "actually" just an `i64` pointer, and wewant to do `i64`-y things with it, such as an `iadd` to compute a derivedpointer, but `iadd` only takes integer types and not `r64`s. We investigatedloosening that restriction and it was way too painful given the way that CLIFtype inference and its controlling type vars work. So to compute those derivedpointers, we have to first `bitcast` the `r64` into an `i64`. This isunfortunate in two ways. First, because of arcane interactions between registerallocation constraints, stack maps, and ABIs this involves inserting unnecessaryregister-to-register moves in our generated code which hurts binary size andperformance ever so slightly. Second, and much more seriously, this is a seriousfootgun. If a GC reference isn't an `r64` right now, then it will not appear instack maps, and failure to record a live GC reference in a stack map means thatthe collector could reclaim the object while you are still using it, leading touse-after-free bugs! Very bad. And the mid-end needs to know*not* to GVN these bitcasts or else we get similar bugs (seehttps://github.com/bytecodealliance/wasmtime/pull/8317).Overall GC references are a painful situation for us today.This commit is the introduction of an alternative. (Note, though, that we aren'tquite ready to remove the old stack maps infrastructure just yet.)Instead of preserving GC references all the way through the whole pipeline andcomputing live GC references and inserting spills at safepoints for stack mapsall the way at the end of that pipeline in register allocation, theCLIF-producing frontend explicitly generates its own stack slots and spills forsafepoints. The only thing the rest of the compiler pipeline needs to know isthe metadata required to produce the stack map for the associated safepoint. Wecan completely remove `r32` and `r64` from Cranelift and just use plain `i32`and `i64` values. Or `f64` if the runtime uses NaN-boxing, which the old stackmaps system did not support at all. Or 32-bit GC references on a 64-bit target,which was also not supported by the old system. Furthermore, we *cannot* getmiscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren'tany bitcasts hiding GC references from stack maps anymore. And in the case of amoving GC, we don't need to worry about the mid-end doing illegal code motionacross calls that could have triggered a GC that invalidated the moved GCreference because frontends will reload their GC references from the stack slotsafter the call, and that loaded value simply isn't a candidate for GVN with theprevious version. We don't have to worry about those bugs by construction.So everything gets a lot easier under this new system.But this commit doesn't mean we are 100% done and ready to transition to the newsystem, so what is actually in here?* CLIF producers can mark values as needing to be present in a stack map if theyare live across a safepoint in `cranelift-frontend`. This is the`FunctionBuilder::declare_needs_stack_map` method.* When we finalize the function we are building, we do a simple, single-passliveness analysis to determine the set of GC references that are live at eachsafepoint, and then we insert spills to explicit stack slots just before thesafepoint. We intentionally trade away the precision of a fixed-point livenessanalysis for the speed and simplicity of a single-pass implementation.* We annotate the safepoint with the metadata necessary to construct itsassociated stack map. This is the new`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method andall that stuff.* These stack map entries are part of the CLIF and can be roundtripped throughprinting and parsing CLIF.* Each stack map entry describes a GC-managed value that is on the stack and howto locate it: its type, the stack slot it is located within, and the offsetwithin that stack slot where it resides. Different stack map entries for thesame safepoint may have different types or a different width from the target'spointer.Here is what is *not* handled yet, and left for future follow up commits:* Lowering the stack map entries' locations from symbolic stack slot and offsetpairs to physical stack frame offsets after register allocation.* Coalescing and aggregating the safepoints and their raw stack map entries intoa compact PC-to-stack-map table during emission.* Supporting moving GCs. Right now we generate spills into stack slots for liveGC references just before safepoints, but we don't reload the GC references fromthe stack upon their next use after the safepoint. This involves rewriting usesof the old, spilled values which could be a little finicky, but we think we havea good approach.* Port Wasmtime over to using this new stack maps system.* Removing the old stack map system, including `r{32,64}` from Cranelift and GCreference handling from `regalloc2`. (For the time being, the new systemgenerally refers to "user stack maps" to disambiguate from the old system whereit might otherwise be confusing.) If we wanted to remove the old system now,that would require us to also port Wasmtime to the new system now, and we'd endup with a monolithic PR. Better to do this incrementally and temporarily havethe old and in-progress new system overlap for a short period of time.Co-authored-by: Trevor Elliott List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/user_stack_maps.rs

Changes in user_stack_maps.rs

b81ef46c - Remove reference types (`r32` and `r64`) from Cranelift (#9164)

c0c3a68c - Cranelift: Remove the old stack maps implementation (#9159)

b2025ead - Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)

e20b4244 - Cranelift: Take user stack maps through lowering and emission (#8876)

59de3a32 - Cranelift: Allow CLIF frontends to define their own stack maps (#8728)