<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in write.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>2f7dbd61 - PCC: remove proof-carrying code (for now?). (#12800)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#2f7dbd61</link>
        <description>PCC: remove proof-carrying code (for now?). (#12800)In late 2023, we built out an experimental feature calledProof-Carrying Code (PCC), where we attached &quot;facts&quot; to values in theCLIF IR and built verification of these facts after lowering tomachine instructions. We also added &quot;memory types&quot; describing layoutof memory and a &quot;checked&quot; flag on memory operations such that we couldverify that any checked memory operation accessed valid memory (asdefined by memory types attached to pointer values viafacts). Wasmtime&apos;s Cranelift backend then put appropriate memory typesand facts in its IR such that all accesses to memory (aspirationally)could be checked, taking the whole mid-end and lowering backend ofCranelift out of the trusted core that enforces SFI.This basically worked, at the time, for static memories; but never fordynamic memories, and then work on the feature lostprioritization (aka I had to work on other things) and I wasn&apos;t ableto complete it and put it in fuzzing/enable it as a production option.Unfortunately since then it has bit-rotted significantly -- as we addnew backend optimizations and instruction lowerings we haven&apos;t keptthe PCC framework up to date.Inspired by the discussion in #12497 I think it&apos;s time to deleteit (hopefully just &quot;for now&quot;?) unless/until we can build it again. Andwhen we do that, we should probably get it to the point of validatingrobust operation on all combinations of memory configurations beforemerging. (That implies a big experiment branch rather than a bunch ofeager PRs in-tree, but so it goes.) I still believe it is possible tobuild this (and I have ideas on how to do it!) but not right now.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Tue, 31 Mar 2026 04:36:33 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>d70a517c - Print stack maps for `try_call[_indirect]` CLIF instructions (#12891)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#d70a517c</link>
        <description>Print stack maps for `try_call[_indirect]` CLIF instructions (#12891)* Print stack maps for `try_call[_indirect]` CLIF instructionsThe safepoint liveness analysis already correctly records stack maps for theseinstructions, but the display omission hid this from view.* cargo fmt

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Mon, 30 Mar 2026 18:35:17 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>a3d6e407 - Cranelift: add debug tag infrastructure. (#11768)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#a3d6e407</link>
        <description>Cranelift: add debug tag infrastructure. (#11768)* Cranelift: add debug tag infrastructure.This PR adds *debug tags*, a kind of metadata that can attach to CLIFinstructions and be lowered to VCode instructions and as metadata onthe produced compiled code. It also adds opaque descriptor blobscarried with stackslots. Together, these two features allow decoratingIR with first-class debug instrumentation that is properly preservedby the compiler, including across optimizations andinlining. (Wasmtime&apos;s use of these features will come in followupPRs.)The key idea of a &quot;debug tag&quot; is to allow the Cranelift embedder toexpress whatever information it needs to, in a format that is opaqueto Cranelift itself, except for the parts that need translation duringlowering. In particular, the `DebugTag::StackSlot` variant getstranslated to a physical offset into the stackframe in the compiledmetadata output. So, for example, the embedder can emit a tagreferring to a stackslot, and another describing an offset in thatstackslot.The debug tags exist as a *sequence* on any given instruction; themeaning of the sequence is known only to the embedder, *except* thatduring inlining, the tags for the inlining call instruction areprepended to the tags of inlined instructions. In this way, acanonical use-case of tags as describing original source-languageframes can preserve the source-language view even when multiplefunctions are inlined into one.The descriptor on a stackslot may look a little odd at first, but itspurpose is to allow serializing some description ofstackslot-contained runtime user-program data, in a way that is firmlyattached to the stackslot. In particular, in the face of inlining,this descriptor is copied into the inlining (parent) function from theinlined function when the stackslot entity is copied; no othermetadata outside Cranelift needs to track the identity of stackslotsand know about that motion. This fits nicely with the ability of tagsto refer to stackslots; together, the embedder can annotateinstructions as having certain state in stackslots, and describe theformat of that state per stackslot.This infrastructure is tested with some compile-tests now;testing of the interpretation of the metadata output will come withend-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.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Mon, 06 Oct 2025 19:38:03 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>4c01ee2f - Cranelift: add get_exception_handler_address. (#11629)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#4c01ee2f</link>
        <description>Cranelift: add get_exception_handler_address. (#11629)* Cranelift: add get_exception_handler_address.This is designed to enable applications such as #11592 that usealternative unwinding mechanisms that may not necessarily want to walk astack and look up exception tables. The idea is that whenever it wouldbe 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 befound in the exception table for the given handler edge. A &quot;custom&quot;resume step can then use this PC as a resume-point as long as it followsthe relevant exception ABI (i.e.: restore SP, FP, any other savedregisters that the exception ABI specifies, and provide appropriatepayload value(s)).Handlers are associated with edges out of `try_call`s (or`try_call_indirect`s); and edges specifically, not blocks, because therecould be multiple out-edges to one block. The instruction thus takes theblock that contains the try-call and an immediate that indexes itsexceptional edges.This CLIF instruction required a bit of infrastructure to (i) allownaming raw blocks, not just block calls, as instruction arguments, and(ii) allow getting the MachLabel for any other lowered block duringlowering. But given that, the lowerings themselves are straightforwarduses of MachBuffer labels to fix-up PC-relative address-loadinginstructions (e.g., `LEA` or `ADR` or `AUIPC`+`ADDI`).* Review feedback.* Review feedback: more tests.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Fri, 05 Sep 2025 22:41:46 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>099102d9 - Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen (#11182)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#099102d9</link>
        <description>Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen (#11182)* Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegenThis commit gets around to migrating the `cranelift-codegen` crate torequire a reason on lint directives and additionally switch to`#[expect]` where possible.prtest:full* Move x64-only item to x64 backend

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Mon, 07 Jul 2025 17:25:40 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>3da7fc8e - [DI] Dump value label assignments in a table (#10549)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#3da7fc8e</link>
        <description>[DI] Dump value label assignments in a table (#10549)* Dump compilation start/end* [DI] Log value label ranges in a tableSample 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.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Tue, 08 Apr 2025 19:42:14 +0000</pubDate>
        <dc:creator>SingleAccretion &lt;62474226+SingleAccretion@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>94ec88ea - Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#94ec88ea</link>
        <description>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, andlowerings on four of five ISAs (x86-64, aarch64, riscv64, pulley; s390xhas 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 thatcarry the normal return values or exception payloads (respectively) intothe appropriate successor blocks.It wires up the &quot;normal return path&quot; so that it continues to work.It updates the ABI so that unwinding is possible without an initialregister state at throw: specifically, as per our RFC, all registers areclobbered. It also includes metadata in the `MachBuffer` that describesexception-catch destinations. However, no unwinder exists to interpretthese catch-destinations yet, so they are untested.* Add try_call_indirect lowering as well.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Tue, 08 Apr 2025 00:02:16 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#a0442ea0</link>
        <description>Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Mon, 05 Aug 2024 09:59:59 +0000</pubDate>
        <dc:creator>Hamir Mahal &lt;hamirmahal@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>0683b84b - Cranelift: Stop sign-extending `Imm64` immediates in builder methods (#9046)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#0683b84b</link>
        <description>Cranelift: Stop sign-extending `Imm64` immediates in builder methods (#9046)* Cranelift: Stop sign-extending `Imm64` immediates in builder methodsOriginally, we sign-extended `Imm64` immediates from their controlling typevar&apos;s width to `i64` in the builder methods for `BinaryImm64` and a couple otherinstruction formats: https://github.com/bytecodealliance/wasmtime/pull/1687At some point, we decided that the unused bits in the `Imm64` when thecontrolling type var&apos;s width is less than 64 should be zero. And we startedasserting that in various places, for example:https://github.com/bytecodealliance/wasmtime/blob/87817f38a128caa76eaa6a3c3c8ceac81a329a3e/cranelift/codegen/src/machinst/lower.rs#L1237-L1243However, we never removed or updated the sign-extension code in the buildermethods. This commit switches the builder methods over to masking the `Imm64` tojust the valid bits, effectively doing a zero extend from the controlling typevar&apos;s width instead of a sign extend.To avoid too much churn in tests, I made `display_inst` print thesign-extended-from-the-controlling-type-variable&apos;s-width value of `Imm64`immediates. I also made the `Display` implementation for `Imm64` always print indecimal form with a `-` for negative numbers, rather than the hex it wouldpreviously print for large negative numbers, so that `iconst.i32 0x8000_0000`doesn&apos;t display as `iconst.i32 0xffff_ffff_8000_0000`, which is otherwise prettyconfusing.* Rename condition* return new immediates instead of mutating* Update some test expectations

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Wed, 31 Jul 2024 00:05:28 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>41eca60b - cranelift: Add `f16const` and `f128const` instructions (#8893)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#41eca60b</link>
        <description>cranelift: Add `f16const` and `f128const` instructions (#8893)* cranelift: Add `f16const` and `f128const` instructions* cranelift: Add constant propagation for `f16` and `f128`

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Wed, 17 Jul 2024 16:39:47 +0000</pubDate>
        <dc:creator>beetrees &lt;b@beetr.ee&gt;</dc:creator>
    </item>
<item>
        <title>59de3a32 - Cranelift: Allow CLIF frontends to define their own stack maps (#8728)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#59de3a32</link>
        <description>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 &quot;actually&quot; 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&apos;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&apos;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&apos;ing bitcasts that shouldn&apos;t be GVN&apos;d because there aren&apos;tany bitcasts hiding GC references from stack maps anymore. And in the case of amoving GC, we don&apos;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&apos;t a candidate for GVN with theprevious version. We don&apos;t have to worry about those bugs by construction.So everything gets a lot easier under this new system.But this commit doesn&apos;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&apos;spointer.Here is what is *not* handled yet, and left for future follow up commits:* Lowering the stack map entries&apos; 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&apos;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 &quot;user stack maps&quot; 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&apos;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 &lt;telliott@fastly.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Fri, 07 Jun 2024 04:05:56 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>689f7d48 - Remove the last references to boolean types (#8699)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#689f7d48</link>
        <description>Remove the last references to boolean types (#8699)

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Tue, 28 May 2024 17:27:32 +0000</pubDate>
        <dc:creator>Trevor Elliott &lt;telliott@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>45bc7366 - Cranelift: add alignment parameter to stack slots. (#8635)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#45bc7366</link>
        <description>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-wordboundary. This is insufficient for some use-cases: for example, storingSIMD 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 theshared ABI code to compute the stackslot layout taking the alignmentinto 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 reviewCo-authored-by: Trevor Elliott &lt;awesomelyawesome@gmail.com&gt;* Update filetest.* Update alignment to ValRaw vector.* Fix printer test.* cargo-fmt from suggestion update.---------Co-authored-by: Trevor Elliott &lt;awesomelyawesome@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Thu, 16 May 2024 16:48:27 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>138148a5 - Resolve value aliases in disas tests (#8239)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#138148a5</link>
        <description>Resolve value aliases in disas tests (#8239)This reverts commit 6c5184809db3a92de4ee0c718c403bedc9a9ff4f,&quot;Cranelift: resolve value aliases when printing CLIF functions (#8214)&quot;,then applies the same effect a different way.In discussion on #8223, we decided to handle this a different way. SoI&apos;ve introduced a method on DataFlowGraph which eliminates all valuealiases, and we can call it when necessary. If that function is notcalled then the CLIF printer should print value aliases the same way itdid before #8214.In this PR, I&apos;ve specifically called it in disas tests. The changes towrite.rs and frontend.rs are from the revert, while the changes todisas.rs are new.In these tests, value aliases are just clutter that distracts fromunderstanding what code will actually be generated. They may change dueto changes in legalization, but that doesn&apos;t signal anything aboutwhatever the test was intended to check.Because the new helper deletes aliases after it&apos;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.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Tue, 26 Mar 2024 06:36:54 +0000</pubDate>
        <dc:creator>Jamey Sharp &lt;jsharp@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>6c518480 - Cranelift: resolve value aliases when printing CLIF functions (#8214)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#6c518480</link>
        <description>Cranelift: resolve value aliases when printing CLIF functions (#8214)This makes the CLIF much easier to follow.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Fri, 22 Mar 2024 01:24:49 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>c4478334 - cranelift: Remove support for WebAssembly tables (#8124)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#c4478334</link>
        <description>cranelift: Remove support for WebAssembly tables (#8124)Wasmtime no longer needs any of this infrastructure and neither shouldanybody else.This diff is nearly identical to @bjorn3&apos;s version of the same change,except I didn&apos;t remove Uimm64, which has started being used in otherplaces. I forgot bjorn3 had already tackled this part until after I wasalready done, but it&apos;s reassuring that we both made the same changes.https://github.com/bjorn3/wasmtime/commit/fb82ccb3948e949641a6d9581aa84472f68f97b8Fixes #5532

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Thu, 14 Mar 2024 15:40:25 +0000</pubDate>
        <dc:creator>Jamey Sharp &lt;jsharp@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>8e00cc20 - PCC: initial end-to-end integration with Wasmtime&apos;s static memories. (#7274)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#8e00cc20</link>
        <description>PCC: initial end-to-end integration with Wasmtime&apos;s static memories. (#7274)* PCC: add facts to global values, parse and print them. No verification yet.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* PCC: propagate facts on GV loads and check them.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* PCC: support propagating facts on iteratively-elaborated GVs as well.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* PCC: fix up Wasmtime uses of GVs after refactors to memflags handling.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* PCC: working end-to-end for static memories!Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* 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 &lt;fitzgen@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Tue, 17 Oct 2023 23:52:34 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>1ced3e8e - PCC: add basic &quot;memory types&quot;. (#7219)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#1ced3e8e</link>
        <description>PCC: add basic &quot;memory types&quot;. (#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 &lt;fitzgen@gmail.com&gt;* Transition `points_to` to a `memory` (static memory) memory-type.* Review feedback.---------Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Thu, 12 Oct 2023 00:02:09 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>f466aa26 - Skeleton and initial support for proof-carrying code. (#7165)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#f466aa26</link>
        <description>Skeleton and initial support for proof-carrying code. (#7165)* WIP veriwasm 2.0Co-Authored-By: Chris Fallin &lt;cfallin@fastly.com&gt;* PCC: successfully parse some simple facts.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* PCC: plumb facts through VCode and add framework on LowerBackend to check them.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* PCC: code is carrying some proofs! Very simple test-case.Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;* 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 &lt;fitzgen@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Fri, 06 Oct 2023 22:31:23 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>f4013e4c - Fix table_addr parsing/printing (#6334)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/write.rs#f4013e4c</link>
        <description>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

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/write.rs</description>
        <pubDate>Wed, 03 May 2023 18:36:06 +0000</pubDate>
        <dc:creator>Trevor Elliott &lt;telliott@fastly.com&gt;</dc:creator>
    </item>
</channel>
</rss>
