<?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 mod.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/machinst/mod.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/machinst/mod.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>0889323a - cranelift-codegen: rename most uses of std to core and alloc (#12237)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#0889323a</link>
        <description>cranelift-codegen: rename most uses of std to core and alloc (#12237)* rename most std uses to core and alloc* cargo fmt

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Sat, 03 Jan 2026 00:54:48 +0000</pubDate>
        <dc:creator>SSD &lt;96286755+the-ssd@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>17fbd3c6 - Debug: implement breakpoints and single-stepping. (#12133)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#17fbd3c6</link>
        <description>Debug: implement breakpoints and single-stepping. (#12133)* Debug: implement breakpoints and single-stepping.This is a PR that puts together a bunch of earlier pieces (patchablecalls in #12061 and #12101, private copies of code in #12051, and allthe prior debug event and instrumentation infrastructure) to implementbreakpoints in the guest debugger.These are implemented in the way we have planned in #11964: eachsequence point (location prior to a Wasm opcode) is now a patchable callinstruction, patched out (replaced with NOPs) by default. When patchedin, the breakpoint callsite calls a trampoline with the `patchable` ABIwhich then invokes the `breakpoint` hostcall. That hostcall emits thedebug event and nothing else.A few of the interesting bits in this PR include:- Implementations of &quot;unpublish&quot; (switch permissions back to read/write  from read/execute) for mmap&apos;d code memory on all our platforms.- Infrastructure in the frame-tables (debug info) metadata producer and  parser to record &quot;breakpoint patches&quot;.- A tweak to the NOP metadata packaged with the `MachBuffer` to allow  multiple NOP sizes. This lets us use one 5-byte NOP on x86-64, for  example (did you know x86-64 had these?!) rather than five 1-byte  NOPs.This PR also implements single-stepping with a global-per-`Store` flag,because at this point why not; it&apos;s a small additional bit of logic todo *all* patches in all modules registered in the `Store` when that flagis enabled.A few realizations for future work:- The need for an introspection API available to a debugger to see the  modules within a component is starting to become clear; either that,  or the &quot;module and PC&quot; location identifier for a breakpoint switches  to a &quot;module or component&quot; sum type. Right now, the tests for this  feature use only core modules. Extending to components should not  actually be hard at all, we just need to build the API for it.- The interaction between inlining and `patchable_call` is interesting:  what happens if we inline a `patchable_call` at a `try_call` callsite?  Right now, we do *not* update the `patchable_call` to a `try_call`,  because there is no `patchable_try_call`; this is fine in the Wasmtime  embedding in practice because we never (today!) throw exceptions from  a breakpoint handler. This does suggest to me that maybe we should  make patchability a property of any callsite, and allow try-calls to  be patchable too (with the same restriction about no return values as  the only restriction); but happy to discuss that one further.* Add missing debug.wat disas test.* Review feedback.* Fix comment on `CodeMemory::text_mut`.* Review feedback.* Review feedback: abort process on failure to re-apply executable permissions.* Implement icache flush for aarch64.This appears to be necessary as we otherwise see a failure in CI onmacOS/aarch64 that is consistent with patched-in breakpoint calls stillbeing incorrectly cached after we remove them and republish the code.There is a longstanding issue in #3310 tracking proper icache coherencehandling on aarch64. We implemented this for Linux with the `membarrier`syscall but never did so for macOS. Maybe this is the first point atwhich it matters, because code was always loaded at new addresses (hencedid not have coherence issues because nothing would have been cached)previously.prtest:full* Review feedback: use `next_multiple_of`.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Fri, 12 Dec 2025 20:02:54 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>c00e9ea2 - Cranelift: add patchable call instructions. (#12101)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#c00e9ea2</link>
        <description>Cranelift: add patchable call instructions. (#12101)* Cranelift: add patchable call instructions.The new `patchable_call` CLIF instruction pairs with the `patchable`ABI, and emits a callsite with one new key property: the MachBuffercarries metadata that describes exactly which byte range to &quot;NOP out&quot;(overwrite with NOP instructions) to disable that callsite. Doing so issemantically valid and explicitly supported.This enables patching of code at runtime to dynamically turn on and offfeatures such as instrumentation or debugging hooks. We plan to use thisto implement breakpoints in Wasmtime&apos;s guest debugging support.As part of this change, I added a notion of &quot;unit of NOP bytes&quot; to theMachBuffer so that the consumer (e.g., Wasmtime&apos;s Cranelift-based codecompilation pipeline and metadata-producing logic) can handle patchablecallsites without any other special knowledge of the ISA.For the &quot;real metal&quot; ISAs there are perfectly well-defined NOPs to use,but for Pulley, where all opcodes are assigned at compile time by macromagic, I explicitly defined NOP as opcode byte 0 by moving `Nop`&apos;sdefinition to the top of the list and adding a unit test asserting itsencoding.A design note: in principle it would be possible, as an alternative, totreat &quot;patchability&quot; as an orthogonal dimension of all callsites, andemit the metadata describing the instruction-offset range for anycallsite with the flag set. The only truly necessary semanticrestriction is that there are no return values (because if we turn thecallsite off, nothing writes to them); we could support patchability forother ABIs and for the other kinds of call instructions. The `patchable`ABI would then be better described as something like the &quot;no clobbersABI&quot;. I opted not to generalize in this way because it creates someless-tested corners and the generalized form, at least at the MachInstlevel, is not really much simpler in the end.A testing note: I opted not to implement actual code patching in the`cranelift-tools` filetest runner and test patching callsites in/out viasome actuation (e.g. a magic hostcall, like we do for throws) because(i) that&apos;s a lot of new plumbing and (ii) we are going to test this veryshortly in Wasmtime anyway and (iii) the correctness (or not) of thelocation-and-length metadata is easy enough to verify in thedisassemblies in the compile-tests.* Review feedback: remove dependence on (and test for) NOP being the literal byte 0.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Tue, 02 Dec 2025 00:59:15 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>557cc2d6 - Another batch of dependency updates (#11832)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#557cc2d6</link>
        <description>Another batch of dependency updates (#11832)* Another batch of dependency updatesBringing some deps in `Cargo.toml` up-to-date with their latest versionsalong the same lines as #11820 to avoid deps getting too stale/old.Code-wise this updates `anyhow` which enables preexisting Clippywarnings to check more code, so those warnings are fixed here as well.prtest:full* Run rustfmt

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Fri, 10 Oct 2025 17:12:23 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.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/machinst/mod.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/machinst/mod.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>3b85d838 - feat: add granular tail call detection infrastructure to MachInst (#11599)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#3b85d838</link>
        <description>feat: add granular tail call detection infrastructure to MachInst (#11599)* feat: add granular tail call detection infrastructure to machinstAdds core infrastructure for distinguishing between regular calls andtail calls at the instruction level.* feat: implement call_type() method for all ISA backends* refactor: pass around function_calls enum instead of boolean* feat: add function_calls.update() logic

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Wed, 03 Sep 2025 22:47:50 +0000</pubDate>
        <dc:creator>Paul Nodet &lt;5941125+pnodet@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>3fe9c3c7 - fix: accurate leaf detection (#11581)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#3fe9c3c7</link>
        <description>fix: accurate leaf detection (#11581)* feat: add is_call() method to MachInst trait and VCode analysisAdd is_call() method to MachInst trait to enable accurate leaf functiondetection during register allocation. Update VCode compute_clobbers() toreturn (clobbers, is_leaf) tuple by analyzing actual call instructionsin machine code.* feat: implement is_call() method across all architecturesImplement is_call() method for all architecture-specific MachInstimplementations:- x64: Detects CallKnown, CallUnknown, ReturnCall variants, and TLScalls (ElfTlsGetAddr, MachOTlsGetAddr)- aarch64: Detects Call, CallInd, ReturnCall variants, and TLS calls(ElfTlsGetAddr, MachOTlsGetAddr)- riscv64: Detects Call, CallInd, ReturnCall variants, and ElfTlsGetAddr- s390x: Detects CallKnown, CallUnknown, ReturnCall variants- pulley: Detects Call, CallIndirect, ReturnCall variantsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* feat: improve leaf function detection and pass is_leaf to FrameLayout* test: add filetests for leaf detection* test: update expected outputs for accurate leaf function detection* test(riscv64): update filetests output---------Co-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Wed, 03 Sep 2025 15:57:55 +0000</pubDate>
        <dc:creator>Paul Nodet &lt;5941125+pnodet@users.noreply.github.com&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/machinst/mod.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/machinst/mod.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>90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#90ac295e</link>
        <description>Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it&apos;s possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Mon, 19 May 2025 16:40:55 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.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/machinst/mod.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/machinst/mod.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>a62b396f - Cranelift: remove return-value instructions after calls at callsites. (#10502)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#a62b396f</link>
        <description>Cranelift: remove return-value instructions after calls at callsites. (#10502)* Cranelift: remove return-value instructions after calls at callsites.This PR addresses the issues described in #10488 in a more head-onway: it removes the use of separate &quot;return-value instructions&quot; thatload return values from the stack, instead folding these loads intothe semantics of the call VCode instruction.This is a prerequisite for exception-handling: we need calls to beworkable as terminators, meaning that we cannot require anyother (VCode) instructions after the call to define the return values.In principle, this PR starts simply enough: the return-locations liston the `CallInfo` that each backend uses to provide regalloc metadatais updated to support a notion of &quot;register or stack address&quot; as thesource of each return value, and this list is now used for both kindsof returns, not just returns in registers. Shared code is defined in`machinst::abi` used by all backends to perform the requisite loads.In order to make this work with more defined values than fit inregisters, however, this PR also had to add support for&quot;any&quot;-constrained registers to Cranelift, and handling allocationsthat may be spillslots. This has always been supported by RA2, butthis is the first time that Cranelift uses them directly (previouslythey were used only internally in RA2 as lowerings from other kinds ofconstraints like safepoints). This requires encoding a spillslot indexin our `Reg` type.There is a little bit of complexity around handling the loads/defs aswell: if we have a return value on-stack, and we need to put it in aspillslot, we cannot do a memory-to-memory move directly, so we need atemporary register. Earlier versions of this PR allocated another tempas a vreg on the call, but this doesn&apos;t work with all callingconventions (too many clobbers). For simplicity I picked a particularregister that is (i) clobbered by calls and (ii) not used for returnvalues for each architecture (x86-64&apos;s tailcall needed to lose onereturn-in-register slot to make this work).This removes retval insts from the shared ABI infra completely. s390xis different, still, because it handles callsite lowering from ISLE;we will need to address that separately for exception support there.* Fix is_included_in_clobbers on aarch64: new defs must skip optimization.* Review feedback: add assert.* Review feedback: handle retval temp reg via ABI trait method.* Update is_clobbered_in_inst to affect only clobbers, not all defs.

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Sat, 05 Apr 2025 05:01:13 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>392c7a96 - Cranelift/x64 backend: do not use one-way branches. (#10086)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#392c7a96</link>
        <description>Cranelift/x64 backend: do not use one-way branches. (#10086)* Cranelift/x64 backend: do not use one-way branches.In #9980, we saw that code copmiled with the single-pass registerallocator has incorrect behavior. We eventually narrowed this down tothe fact that the single-pass allocator is inserting code meant to beat the end of a block, just before its terminator, *between* twobranches that form the terminator sequence. The allocator is correct;the bug is with Cranelift&apos;s x64 backend.When we produce instructions into a VCode container, we maintain basicblocks, and we have the invariant (usual for basic block-based IR)that only the last -- terminator -- instruction is a branch that canleave the block. Even the conditional branches maintain thisinvariant: though VCode is meant to be &quot;almost machine code&quot;, weemit *two-target conditionals* that are semantically like &quot;jcond;jmp&quot;. We then are able to optimize this inline during binary emissionin the `MachBuffer`: the buffer knows about unconditional andconditional branches and will &quot;chomp&quot; branches off the tail of thebuffer whenever they target the fallthrough block. (We designed thesystem this way because it is simpler to think about BBs that areorder-invariant, i.e., not bake the &quot;fallthrough&quot; concept into theIR.) Thus we have a simpler abstraction but produce optimal terminatorsequences.Unfortunately, when adding a branch-on-floating-point-comparelowering, we had the need to branch to a target if either of *two*conditions were true, and rather than add a new kind of terminatorinstruction, we added a &quot;one-armed branch&quot;: conditionally branch tolabel or fall through. We emitted this in sequence right before theactual terminator, so semantically it was almost equivalent.I write &quot;almost&quot; because the register allocator *is* allowed to insertspills/reloads/moves between any two instructions. Here the distinctpieces of the terminator sequence matter: the allocator might insertsomething just before the last instruction, assuming the basic-block&quot;single in, single out&quot; invariant means this will always run with theblock. With one-armed branches this is no longer true.The backtracking allocator (our original RA2 algorithm, and still thedefault today) will never insert code at the end of a block when ithas multiple terminators, because it associates such block-start/endinsertions with *edges*; so in such conditions it inserts instructionsinto the tops of successor blocks instead. But the single-passallocator needs to perform work at the end of every block, so it willtrigger this bug.This PR removes `JmpIf` and converts the br-of-fcmp lowering to use`JmpCondOr` instead, which is a pseudoinstruction that does `jcc1;jcc2; jmp`. This maintains the BB invariant and fixes the bug.Note that Winch still uses `JmpIf`, so we cannot remove it entirely:this PR renames it to `WinchJmpIf` instead, and adds a mechanism toassert failure if it is ever added to `VCode` (rather than emitteddirectly, as Winch&apos;s macro-assembler does). We could instead writeWinch&apos;s `jmp_if` assembler function in terms of `JmpCond` with afallthrough label that is immediately bound, and let the MachBufferalways chomp the jmp; I opted not to regress Winch compilerperformance by doing this. If one day we abstract out the assemblerfurther, we can remove `WinchJmpIf`.This is one of two instances of a &quot;one-armed branch&quot;; the other iss390x&apos;s `OneWayCondBr`, used in `br_table` lowerings, which we willaddress separately. Once we do, that will address #9980 entirely.* Add test for cascading branch-chomping behavior.* keep the paperclip happy

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Thu, 23 Jan 2025 02:30:01 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>438fc938 - pulley: Implement interpreter-to-host calls (#9665)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#438fc938</link>
        <description>pulley: Implement interpreter-to-host calls (#9665)* pulley: Implement interpreter-to-host callsThis commit is an initial stab at implementing interpreter-to-hostcommunication in Pulley. The basic problem is that Pulley needs theability to call back into Wasmtime to implement tasks such as`memory.grow`, imported functions, etc. For native platforms this is asimple `call_indirect` operation in Cranelift but the story for Pulleymust be different because it&apos;s effectively switching from interpretedcode to native code.The initial idea for this in #9651 is replaced here and looks mostlysimilar but with a few changes. The overall structure of how this worksis:* A new `call_indirect_host` opcode is added to Pulley.  * Function signatures that can be called from Pulley bytecode are    statically enumerated at build-time.  * This enables the implementation of `call_indirect_host` to take an    immediate of which signature is being used and cast the function    pointer to the right type.* A new pulley-specific relocation is added to Cranelift for this opcode.  * `RelocDistance::Far` calls to a name trigger the use of    `call_indirect_host`.  * The relocation is filled in by Wasmtime after compilation where the    signature number is inserted.  * A new `NS_*` value for user-function namespaces is reserved in    `wasmtime-cranelift` for this new namespace of functions.* Code generation for Pulley in `wasmtime-cranelift` now has  Pulley-specific handling of the wasm-to-host transition where all  previous `call_indirect` instructions are replaced with a call to a  &quot;backend intrinsic&quot; which gets lowered to a `call_indirect_host`.Note that most of this still isn&apos;t hooked up everywhere in Wasmtime.That means that the testing here is pretty light at this time. It&apos;llrequire a fair bit more work to get everything fully integrated fromWasmtime in Pulley. This is expected to be one of the significantremaining chunks of work and should help unblock future testing (or makethose diffs smaller ideally).* Review comments

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Mon, 25 Nov 2024 23:12:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>c0c3a68c - Cranelift: Remove the old stack maps implementation (#9159)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#c0c3a68c</link>
        <description>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/machinst/mod.rs</description>
        <pubDate>Wed, 21 Aug 2024 15:28:27 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&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/machinst/mod.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/machinst/mod.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>e20b4244 - Cranelift: Take user stack maps through lowering and emission (#8876)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#e20b4244</link>
        <description>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 &lt;telliott@fastly.com&gt;* 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 &lt;telliott@fastly.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Thu, 27 Jun 2024 18:40:54 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>e165106b - cranelift: Remove nominal-sp (#8643)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#e165106b</link>
        <description>cranelift: Remove nominal-sp (#8643)* Update the frame layout comment* Remove more references to nominal SP* Remove the nominal_sp_offset from backend emit states* Continue removing references to the nominal sp* Remove nominal-sp from the aarch64 backend* Remove nominal-sp from the s390x backend* Remove nominal-sp from the riscv64 backend* Remove old comment

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Fri, 17 May 2024 13:37:43 +0000</pubDate>
        <dc:creator>Trevor Elliott &lt;telliott@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>54e53cc7 - cranelift: Remove the virtual sp offset from all backends (#8631)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#54e53cc7</link>
        <description>cranelift: Remove the virtual sp offset from all backends (#8631)* gen_nominal_sp_adj now returns a smallvec* Remove the virtual sp offset from the x64 backend* Remove the virtual sp offset from the aarch64 backend* Remove the virtual sp offset from the riscv64 backend* Remove the virtual sp offset from the s390x backend* Remove gen_nomninal_sp_adj, and argument area management functions* Remove get_virtual_sp_offset_from_state* Code review suggestions

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Thu, 16 May 2024 18:24:35 +0000</pubDate>
        <dc:creator>Trevor Elliott &lt;telliott@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>7d703191 - cranelift: Delete more unused regalloc-related stuff (#8604)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs#7d703191</link>
        <description>cranelift: Delete more unused regalloc-related stuff (#8604)Part of the ongoing saga of #8524, #8566, #8581, and #8592

            List of files:
            /wasmtime-44.0.1/cranelift/codegen/src/machinst/mod.rs</description>
        <pubDate>Mon, 13 May 2024 05:02:30 +0000</pubDate>
        <dc:creator>Jamey Sharp &lt;jsharp@fastly.com&gt;</dc:creator>
    </item>
</channel>
</rss>
