PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built

PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built verification of these facts after lowering to
machine instructions. We also added "memory types" describing layout
of memory and a "checked" flag on memory operations such that we could
verify that any checked memory operation accessed valid memory (as
defined by memory types attached to pointer values via
facts). Wasmtime's Cranelift backend then put appropriate memory types
and facts in its IR such that all accesses to memory (aspirationally)
could be checked, taking the whole mid-end and lowering backend of
Cranelift out of the trusted core that enforces SFI.

This basically worked, at the time, for static memories; but never for
dynamic memories, and then work on the feature lost
prioritization (aka I had to work on other things) and I wasn't able
to complete it and put it in fuzzing/enable it as a production option.

Unfortunately since then it has bit-rotted significantly -- as we add
new backend optimizations and instruction lowerings we haven't kept
the PCC framework up to date.

Inspired by the discussion in #12497 I think it's time to delete
it (hopefully just "for now"?) unless/until we can build it again. And
when we do that, we should probably get it to the point of validating
robust operation on all combinations of memory configurations before
merging. (That implies a big experiment branch rather than a bunch of
eager PRs in-tree, but so it goes.) I still believe it is possible to
build this (and I have ideas on how to do it!) but not right now.

show more ...

Print stack maps for `try_call[_indirect]` CLIF instructions (#12891)

* Print stack maps for `try_call[_indirect]` CLIF instructions

The safepoint liveness analysis already correctly records stack

Print stack maps for `try_call[_indirect]` CLIF instructions (#12891)

* Print stack maps for `try_call[_indirect]` CLIF instructions

The safepoint liveness analysis already correctly records stack maps for these
instructions, but the display omission hid this from view.

* cargo fmt

show more ...

Cranelift: add debug tag infrastructure. (#11768)

* Cranelift: add debug tag infrastructure.

This PR adds *debug tags*, a kind of metadata that can attach to CLIF
instructions and be lowered to VCo

Cranelift: add debug tag infrastructure. (#11768)

* Cranelift: add debug tag infrastructure.

This PR adds *debug tags*, a kind of metadata that can attach to CLIF
instructions and be lowered to VCode instructions and as metadata on
the produced compiled code. It also adds opaque descriptor blobs
carried with stackslots. Together, these two features allow decorating
IR with first-class debug instrumentation that is properly preserved
by the compiler, including across optimizations and
inlining. (Wasmtime's use of these features will come in followup
PRs.)

The key idea of a "debug tag" is to allow the Cranelift embedder to
express whatever information it needs to, in a format that is opaque
to Cranelift itself, except for the parts that need translation during
lowering. In particular, the `DebugTag::StackSlot` variant gets
translated to a physical offset into the stackframe in the compiled
metadata output. So, for example, the embedder can emit a tag
referring to a stackslot, and another describing an offset in that
stackslot.

The debug tags exist as a *sequence* on any given instruction; the
meaning of the sequence is known only to the embedder, *except* that
during inlining, the tags for the inlining call instruction are
prepended to the tags of inlined instructions. In this way, a
canonical use-case of tags as describing original source-language
frames can preserve the source-language view even when multiple
functions are inlined into one.

The descriptor on a stackslot may look a little odd at first, but its
purpose is to allow serializing some description of
stackslot-contained runtime user-program data, in a way that is firmly
attached to the stackslot. In particular, in the face of inlining,
this descriptor is copied into the inlining (parent) function from the
inlined function when the stackslot entity is copied; no other
metadata outside Cranelift needs to track the identity of stackslots
and know about that motion. This fits nicely with the ability of tags
to refer to stackslots; together, the embedder can annotate
instructions as having certain state in stackslots, and describe the
format of that state per stackslot.

This infrastructure is tested with some compile-tests now;
testing of the interpretation of the metadata output will come with
end-to-end debug instrumentation tests in a followup PR.

* Review feedback: add back sequence points and enforce tags only on sequence points or calls.

* Use Vecs for debug metadata in MachBuffer to avoid SmallVec size penalty in not-used case.

* Review feedback: switch from inlined stackslot descriptor blobs to u64 keys.

show more ...

Cranelift: add get_exception_handler_address. (#11629)

* Cranelift: add get_exception_handler_address.

This is designed to enable applications such as #11592 that use
alternative unwinding mechanis

Cranelift: add get_exception_handler_address. (#11629)

* Cranelift: add get_exception_handler_address.

This is designed to enable applications such as #11592 that use
alternative unwinding mechanisms that may not necessarily want to walk a
stack and look up exception tables. The idea is that whenever it would
be valid to resume to an exception handler that is active on the stack,
we can provide the same PC as a first-class runtime value that would be
found in the exception table for the given handler edge. A "custom"
resume step can then use this PC as a resume-point as long as it follows
the relevant exception ABI (i.e.: restore SP, FP, any other saved
registers that the exception ABI specifies, and provide appropriate
payload value(s)).

Handlers are associated with edges out of `try_call`s (or
`try_call_indirect`s); and edges specifically, not blocks, because there
could be multiple out-edges to one block. The instruction thus takes the
block that contains the try-call and an immediate that indexes its
exceptional edges.

This CLIF instruction required a bit of infrastructure to (i) allow
naming raw blocks, not just block calls, as instruction arguments, and
(ii) allow getting the MachLabel for any other lowered block during
lowering. But given that, the lowerings themselves are straightforward
uses of MachBuffer labels to fix-up PC-relative address-loading
instructions (e.g., `LEA` or `ADR` or `AUIPC`+`ADDI`).

* Review feedback.

* Review feedback: more tests.

show more ...

Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen (#11182)

* Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen

This commit gets around to

Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen (#11182)

* Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen

This commit gets around to migrating the `cranelift-codegen` crate to
require a reason on lint directives and additionally switch to
`#[expect]` where possible.

prtest:full

* Move x64-only item to x64 backend

show more ...

[DI] Dump value label assignments in a table (#10549)

* Dump compilation start/end

* [DI] Log value label ranges in a table

Sample table:

|Inst |IP |VL0 |VL1 |VL3 |VL4 |VL5

[DI] Dump value label assignments in a table (#10549)

* Dump compilation start/end

* [DI] Log value label ranges in a table

Sample table:

|Inst |IP |VL0 |VL1 |VL3 |VL4 |VL5 |VL7 |VL10 |VL11 |VL4294967294|
|--------|----|--------|---------|---------|--------|--------|--------|---------|--------|------------|
|Inst 0 |53 | | | | | | | | | | | | | | | | | | |
|Inst 1 |53 | | | | | | | | | | | | | | | | | | |
|Inst 2 |60 |v194|p2i|v232|p12i| | | | | | | | | | | | |v192|p7i |
|Inst 3 |64 |* |p2i|* |p12i|v231|p13i| | | | | | | | | | |* |p7i |
|Inst 4 |68 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i |
|Inst 5 |72 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i |
|Inst 6 |76 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i |
|Inst 7 |87 |* | |* |p12i|* |p13i| | | | | | | | | | |* |p7i |
|Inst 8 |92 |* | |* |p12i|* |p13i|v227|p0i| | | | | | | | |* |p15i |
|Inst 9 |94 |* | |v204| |v204| |v204| |v204| |v204| |v204| |v204| |* |p15i |
|Inst 10 |100 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i |
|Inst 11 |105 |* | |* | |* | |* | |v226|p9i|* | |* | |* | |* |p15i |
|Inst 12 |109 |* | |* | |* | |* | |* | |v225|p9i|* | |* | |* |p15i |
|Inst 13 |114 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i |
|Inst 14 |119 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i |
|Inst 15 |125 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i |
|Inst 16 |129 |* | |* | |* | |* | |* | |* | |v223|p11i|* | |* |p15i |
|Inst 17 |134 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i |
|Inst 18 |134 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i |
|Inst 19 |139 |* | |* | |* | |* | |* | |* | |* | |v222|p0i|* |p15i |
|Inst 20 |143 |* | |* | |* | |* | |* | |* | |* | |* |p0i|* |p15i |
|Inst 21 |143 |* | |* | |* | |* | |* | |* | |* | |* |p0i|* | |

This will make it much easier to diagnose problems with incomplete/missing live ranges.

show more ...

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

* Cranelift: initial try_call / try_call_indirect (exception) support.

This PR adds `try_call` and `try_call_indirect`

Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)

* Cranelift: initial try_call / try_call_indirect (exception) support.

This PR adds `try_call` and `try_call_indirect` instructions, and
lowerings on four of five ISAs (x86-64, aarch64, riscv64, pulley; s390x
has its own non-shared ABI code that will need separate work).

It extends CLIF to support these instructions as new kinds of branches,
and extends block-calls to accept `retN` and `exnN` block-call args that
carry the normal return values or exception payloads (respectively) into
the appropriate successor blocks.

It wires up the "normal return path" so that it continues to work.
It updates the ABI so that unwinding is possible without an initial
register state at throw: specifically, as per our RFC, all registers are
clobbered. It also includes metadata in the `MachBuffer` that describes
exception-catch destinations. However, no unwinder exists to interpret
these catch-destinations yet, so they are untested.

* Add try_call_indirect lowering as well.

show more ...

Enforce `uninlined_format_args` for the workspace (#9065)

* Enforce `uninlined_format_args` for the workspace

* fix: failing `Monolith Checks` job

* fix: formatting

Cranelift: Stop sign-extending `Imm64` immediates in builder methods (#9046)

* Cranelift: Stop sign-extending `Imm64` immediates in builder methods

Originally, we sign-extended `Imm64` immediates f

Cranelift: Stop sign-extending `Imm64` immediates in builder methods (#9046)

* Cranelift: Stop sign-extending `Imm64` immediates in builder methods

Originally, we sign-extended `Imm64` immediates from their controlling type
var's width to `i64` in the builder methods for `BinaryImm64` and a couple other
instruction formats: https://github.com/bytecodealliance/wasmtime/pull/1687

At some point, we decided that the unused bits in the `Imm64` when the
controlling type var's width is less than 64 should be zero. And we started
asserting that in various places, for example:
https://github.com/bytecodealliance/wasmtime/blob/87817f38a128caa76eaa6a3c3c8ceac81a329a3e/cranelift/codegen/src/machinst/lower.rs#L1237-L1243

However, we never removed or updated the sign-extension code in the builder
methods. This commit switches the builder methods over to masking the `Imm64` to
just the valid bits, effectively doing a zero extend from the controlling type
var's width instead of a sign extend.

To avoid too much churn in tests, I made `display_inst` print the
sign-extended-from-the-controlling-type-variable's-width value of `Imm64`
immediates. I also made the `Display` implementation for `Imm64` always print in
decimal form with a `-` for negative numbers, rather than the hex it would
previously print for large negative numbers, so that `iconst.i32 0x8000_0000`
doesn't display as `iconst.i32 0xffff_ffff_8000_0000`, which is otherwise pretty
confusing.

* Rename condition

* return new immediates instead of mutating

* Update some test expectations

show more ...

cranelift: Add `f16const` and `f128const` instructions (#8893)

* cranelift: Add `f16const` and `f128const` instructions

* cranelift: Add constant propagation for `f16` and `f128`

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

Tracking GC references and producing stack maps is a significant amount of
complexity in `regalloc2`.

At the same time, GC ref

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

Tracking GC references and producing stack maps is a significant amount of
complexity in `regalloc2`.

At the same time, GC reference value types are pretty annoying to deal with in
Cranelift itself. We know our `r64` is "actually" just an `i64` pointer, and we
want to do `i64`-y things with it, such as an `iadd` to compute a derived
pointer, but `iadd` only takes integer types and not `r64`s. We investigated
loosening that restriction and it was way too painful given the way that CLIF
type inference and its controlling type vars work. So to compute those derived
pointers, we have to first `bitcast` the `r64` into an `i64`. This is
unfortunate in two ways. First, because of arcane interactions between register
allocation constraints, stack maps, and ABIs this involves inserting unnecessary
register-to-register moves in our generated code which hurts binary size and
performance ever so slightly. Second, and much more seriously, this is a serious
footgun. If a GC reference isn't an `r64` right now, then it will not appear in
stack maps, and failure to record a live GC reference in a stack map means that
the collector could reclaim the object while you are still using it, leading to
use-after-free bugs! Very bad. And the mid-end needs to know
*not* to GVN these bitcasts or else we get similar bugs (see
https://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't
quite ready to remove the old stack maps infrastructure just yet.)

Instead of preserving GC references all the way through the whole pipeline and
computing live GC references and inserting spills at safepoints for stack maps
all the way at the end of that pipeline in register allocation, the
CLIF-producing frontend explicitly generates its own stack slots and spills for
safepoints. The only thing the rest of the compiler pipeline needs to know is
the metadata required to produce the stack map for the associated safepoint. We
can 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 stack
maps 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* get
miscompiles due to GVN'ing bitcasts that shouldn't be GVN'd because there aren't
any bitcasts hiding GC references from stack maps anymore. And in the case of a
moving GC, we don't need to worry about the mid-end doing illegal code motion
across calls that could have triggered a GC that invalidated the moved GC
reference because frontends will reload their GC references from the stack slots
after the call, and that loaded value simply isn't a candidate for GVN with the
previous 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 new
system, so what is actually in here?

* CLIF producers can mark values as needing to be present in a stack map if they
are 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-pass
liveness analysis to determine the set of GC references that are live at each
safepoint, and then we insert spills to explicit stack slots just before the
safepoint. We intentionally trade away the precision of a fixed-point liveness
analysis for the speed and simplicity of a single-pass implementation.

* We annotate the safepoint with the metadata necessary to construct its
associated stack map. This is the new
`cranelift_codegen::ir::DataFlowGraph::append_user_stack_map_entry` method and
all that stuff.

* These stack map entries are part of the CLIF and can be roundtripped through
printing and parsing CLIF.

* Each stack map entry describes a GC-managed value that is on the stack and how
to locate it: its type, the stack slot it is located within, and the offset
within that stack slot where it resides. Different stack map entries for the
same safepoint may have different types or a different width from the target's
pointer.

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 offset
pairs to physical stack frame offsets after register allocation.

* Coalescing and aggregating the safepoints and their raw stack map entries into
a compact PC-to-stack-map table during emission.

* Supporting moving GCs. Right now we generate spills into stack slots for live
GC references just before safepoints, but we don't reload the GC references from
the stack upon their next use after the safepoint. This involves rewriting uses
of the old, spilled values which could be a little finicky, but we think we have
a 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 GC
reference handling from `regalloc2`. (For the time being, the new system
generally refers to "user stack maps" to disambiguate from the old system where
it 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 end
up with a monolithic PR. Better to do this incrementally and temporarily have
the old and in-progress new system overlap for a short period of time.

Co-authored-by: Trevor Elliott <[email protected]>

show more ...

Remove the last references to boolean types (#8699)

Cranelift: add alignment parameter to stack slots. (#8635)

* Cranelift: add alignment parameter to stack slots.

Fixes #6716.

Currently, stack slots on the stack are aligned only to a machine-word

Cranelift: add alignment parameter to stack slots. (#8635)

* Cranelift: add alignment parameter to stack slots.

Fixes #6716.

Currently, stack slots on the stack are aligned only to a machine-word
boundary. This is insufficient for some use-cases: for example, storing
SIMD data or structs that require a larger alignment.

This PR adds a parameter to the `StackSlotData` to specify alignment,
and the associated logic to the CLIF parser and printer. It updates the
shared ABI code to compute the stackslot layout taking the alignment
into account. In order to ensure the alignment is always a power of two,
it is stored as a shift amount (log2 of actual alignment) in the IR.

* Apply suggestions from code review

Co-authored-by: Trevor Elliott <[email protected]>

* Update filetest.

* Update alignment to ValRaw vector.

* Fix printer test.

* cargo-fmt from suggestion update.

---------

Co-authored-by: Trevor Elliott <[email protected]>

show more ...

Resolve value aliases in disas tests (#8239)

This reverts commit 6c5184809db3a92de4ee0c718c403bedc9a9ff4f,
"Cranelift: resolve value aliases when printing CLIF functions (#8214)",
then applies the s

Resolve value aliases in disas tests (#8239)

This reverts commit 6c5184809db3a92de4ee0c718c403bedc9a9ff4f,
"Cranelift: resolve value aliases when printing CLIF functions (#8214)",
then applies the same effect a different way.

In discussion on #8223, we decided to handle this a different way. So
I've introduced a method on DataFlowGraph which eliminates all value
aliases, and we can call it when necessary. If that function is not
called then the CLIF printer should print value aliases the same way it
did before #8214.

In this PR, I've specifically called it in disas tests. The changes to
write.rs and frontend.rs are from the revert, while the changes to
disas.rs are new.

In these tests, value aliases are just clutter that distracts from
understanding what code will actually be generated. They may change due
to changes in legalization, but that doesn't signal anything about
whatever the test was intended to check.

Because the new helper deletes aliases after it's done resolving them,
those aliases now disappear from the test expectations. Aside from that,
the test expectations are unchanged compared to what #8214 did.

show more ...

Cranelift: resolve value aliases when printing CLIF functions (#8214)

This makes the CLIF much easier to follow.

cranelift: Remove support for WebAssembly tables (#8124)

Wasmtime no longer needs any of this infrastructure and neither should
anybody else.

This diff is nearly identical to @bjorn3's version of t

cranelift: Remove support for WebAssembly tables (#8124)

Wasmtime no longer needs any of this infrastructure and neither should
anybody else.

This diff is nearly identical to @bjorn3's version of the same change,
except I didn't remove Uimm64, which has started being used in other
places. I forgot bjorn3 had already tackled this part until after I was
already done, but it's reassuring that we both made the same changes.

https://github.com/bjorn3/wasmtime/commit/fb82ccb3948e949641a6d9581aa84472f68f97b8

Fixes #5532

show more ...

PCC: initial end-to-end integration with Wasmtime's static memories. (#7274)

* PCC: add facts to global values, parse and print them. No verification yet.

Co-authored-by: Nick Fitzgerald <fitzgen@g

PCC: initial end-to-end integration with Wasmtime's static memories. (#7274)

* PCC: add facts to global values, parse and print them. No verification yet.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: propagate facts on GV loads and check them.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: support propagating facts on iteratively-elaborated GVs as well.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: fix up Wasmtime uses of GVs after refactors to memflags handling.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: working end-to-end for static memories!

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: add toplevel Wasmtime option `-C enable-pcc=y`.

* Fix filetests build.

* Review feedback, and blessed test updates due to GV legalization changes.

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

PCC: add basic "memory types". (#7219)

* PCC: define memory types and add some examples in filetests (no parsing yet).

* PCC: add a notion of memory types.

Co-authored-by: Nick Fitzgerald <fitzgen

PCC: add basic "memory types". (#7219)

* PCC: define memory types and add some examples in filetests (no parsing yet).

* PCC: add a notion of memory types.

Co-authored-by: Nick Fitzgerald <[email protected]>

* Transition `points_to` to a `memory` (static memory) memory-type.

* Review feedback.

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Skeleton and initial support for proof-carrying code. (#7165)

* WIP veriwasm 2.0

Co-Authored-By: Chris Fallin <[email protected]>

* PCC: successfully parse some simple facts.

Co-authored-by: Nic

Skeleton and initial support for proof-carrying code. (#7165)

* WIP veriwasm 2.0

Co-Authored-By: Chris Fallin <[email protected]>

* PCC: successfully parse some simple facts.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: plumb facts through VCode and add framework on LowerBackend to check them.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: code is carrying some proofs! Very simple test-case.

Co-authored-by: Nick Fitzgerald <[email protected]>

* PCC: add a `safe` flag for checked memory accesses.

* PCC: add pretty-printing of facts to CLIF output.

* PCC: misc. cleanups.

* PCC: lots of cleanup.

* Post-rebase fixups and some misc. fixes.

* Add serde traits to facts.

* PCC: add succeed and fail tests.

* Review feedback: rename `safe` memflag to `checked`.

* Review feedback.

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Fix table_addr parsing/printing (#6334)

* Handle the optional table_addr offset when reading/writing clif

* Add a parse test for table_addr round trip

* Update tests

Rework br_table to use BlockCall (#5731)

Rework br_table to use BlockCall, allowing us to avoid adding new nodes during ssa construction to hold block arguments. Additionally, many places where we p

Rework br_table to use BlockCall (#5731)

Rework br_table to use BlockCall, allowing us to avoid adding new nodes during ssa construction to hold block arguments. Additionally, many places where we previously matched on InstructionData to extract branch destinations can be replaced with a use of branch_destination or branch_destination_mut.

show more ...

Move default blocks into jump tables (#5756)

Move the default block off of the br_table instrution, and into the JumpTable that it references.

Inline jump tables in parsed br_table instructions (#5755)

As jump tables are used by at most one br_table instruction, inline their definition in those instructions instead of requiring them to be

Inline jump tables in parsed br_table instructions (#5755)

As jump tables are used by at most one br_table instruction, inline their definition in those instructions instead of requiring them to be declared as function-level metadata.

show more ...

Move jump tables to the DataFlowGraph (#5745)

Move the storage for jump tables off of FunctionStencil and onto DataFlowGraph. This change is in service of #5731, making it easier to access the jump

Move jump tables to the DataFlowGraph (#5745)

Move the storage for jump tables off of FunctionStencil and onto DataFlowGraph. This change is in service of #5731, making it easier to access the jump table data in the context of helpers like inst_values.

show more ...

Add a convenience function for displaying a BlockCall (#5677)

Add a display method to BlockCall that returns a std::fmt::Displayable result. Rework the display code in the write module of cranelift-

Add a convenience function for displaying a BlockCall (#5677)

Add a display method to BlockCall that returns a std::fmt::Displayable result. Rework the display code in the write module of cranelift-codegen to use this method instead.

show more ...