<?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 api.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>63330f11 - cranelift-assembler-x64: no_std support (#12235)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#63330f11</link>
        <description>cranelift-assembler-x64: no_std support (#12235)* cranelift-assembler-x64: no_std support* cargo fmt* Update cranelift/assembler-x64/src/xmm.rsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* Update cranelift/assembler-x64/src/imm.rsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* Update cranelift/assembler-x64/src/api.rsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* Reorder import of alloc* #![no_std]* revert main.rs* cargo fmt* remove core feature* Fix CI---------Co-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Mon, 05 Jan 2026 15:50:37 +0000</pubDate>
        <dc:creator>SSD &lt;96286755+the-ssd@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>79095df3 - x64: Refactor emission of LoadExtName  (#11124)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#79095df3</link>
        <description>x64: Refactor emission of LoadExtName  (#11124)* x64: Expand symbol-related tests* x64: Refactor emission of `LoadExtName`Don&apos;t use raw bytes when emitting this instruction but instead usesymbolic assembler directives to avoid needing to hardcode bytes. Thisadditionally fixes an issue where with `colocated` symbols the offset ofthe symbol was not taken into account (but for Wasmtime it&apos;s always been0 so this otherwise hasn&apos;t come up so far)* Fix emit tests* Update test expectation* Fuse `KnownOffsetTable` and `CodeSink` in the new assemblerEnables a `CodeSink` to know about all offsets, not just those againstlabels. Resolves an issue where the fuzzing code sink was otherwiseunaware of `DeferredTarget::None`.* Review comments

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Wed, 25 Jun 2025 18:06:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>4ff54e00 - x64: Migrate `lea` to the new assembler  (#11084)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#4ff54e00</link>
        <description>x64: Migrate `lea` to the new assembler  (#11084)* x64: Add a shrink-before-emit optimizationThis commit adds a helper function to attempt to shrink a function justbefore emission if possible based on the results of register allocation.While many instructions can be selected ahead of time (e.g. instructionswith smaller immediate widths) some are only possible after registerallocation has happened. For example the `AND RAX, imm32` instruction isnever generated in ISLE because it doesn&apos;t make sense to constrain aregister to only `RAX`, but if register allocation happened to put`AND r/m64, imm32` into `RAX` then it&apos;s possible to use the more compactencoding instead.This function updates the emission of external instructions to, justbefore emission, attempt to pattern-match these instructions and shrinkto a smaller instruction. This is done for a number of instructionswhich support a smaller encoding when the operands are `RAX` and animmediate. In the future my thinking was to use this additionally forthe optimization to change `LEA` instructions into `ADD` instructions ifthe src/destination are equal and the addressing mode matches.* x64: Migrate `lea` to the new assemblerAdding `lea` is easy enough but preserving the optimization ofusing `add` instead of `lea` required a bit of finesse. This hooks intothe `emit_maybe_shrink` added previously for implementing this.* Fix test build

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Fri, 20 Jun 2025 20:17:24 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>4955f5a7 - x64: Migrate `mulx` to the new assembler (#10887)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#4955f5a7</link>
        <description>x64: Migrate `mulx` to the new assembler (#10887)* x64: Migrate `mulx` to the new assemblerThis is an interesting instruction as it has a relatively unique shapecompared to many others. The VEX encoding is used to give it a 3-operandform, although it still has an implicit 4th operand as well. The otherunique part about this instruction is that if the two write-onlyoperands are the same then that has a different semantic meaning than ifthey are different.Modeling the two-output form of the instruction was pretty easy, theonly changes needed were to add the `r32a` and `r32b` locations aspreviously only `r32` was available. Modeling the one-output form of theinstruction led to a &quot;hook&quot; where these instructions specify that theyuse a custom regalloc function. That skips the auto-generated regallocentirely and defers to a new `custom` submodule in the assembler crate.These custom variants handle only having a single write operand on theinstruction.* Fix fuzz build

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Mon, 02 Jun 2025 20:14:46 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>63a8ce3d - x64: Migrate xmm mov-family instructions to new assembler (#10834)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#63a8ce3d</link>
        <description>x64: Migrate xmm mov-family instructions to new assembler (#10834)* x64: Migrate xmm mov-family instructions to new assemblerThis commit migrates xmm movement-style instructions, such as`mov{s{s,d},{a,u}p{s,d},dq{a,u}}` to the new assembler. This enablesdeleting the `XmmMovRM` class of instructions in ISLE. Along the way anumber of notable changes were made:* ISLE constructors for assembler instructions now take `SyntheticAmode`  instead of `Amode` since it&apos;s already supported anyway and it&apos;s a more  flexible argument to take.* The conversion from `SyntheticAmode` to the assembler `Amode&lt;Gpr&gt;` was  fixed where one variant needed to use `rsp` instead of `rbp`.* The `is_move` method was updated to ignore `movss` and `movsd`  instructions since they&apos;re not true movement-related instructions in  register-to-register situations.* Use `gen_move` helper in Winch

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Wed, 28 May 2025 17:27:16 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>10e71fa8 - x64: Convert some lane-manipulation instructions to the new assembler (#10825)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#10e71fa8</link>
        <description>x64: Convert some lane-manipulation instructions to the new assembler (#10825)* x64: Convert some lane-manipulation instructions to the new assemblerThis was mostly straightforward but ended up requiring handling for anew style of instruction not previously before-seen: a write-only`GprMem` operand. This needed some extra treatment/helpers in the ISLEintegration to ensure that this was all hooked up correctly from ISLEconstructors down to the assembler instructions.* Remove `GprToXmm` as wellAlready have mappings for `movd` and `movq`, so let&apos;s migrate this as well.* Remove some old emit tests

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Fri, 23 May 2025 21:17:46 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>b4f041f8 - x64: Migrate div instructions to the new assembler (#10820)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#b4f041f8</link>
        <description>x64: Migrate div instructions to the new assembler (#10820)* x64: Migrate div instructions to the new assemblerThis mostly required adding a new kind of operand representing a`TrapCode` and plumbing around a few bits and bobs to ensure that thiscompile-time-only-abstraction does not need to be accounted for in allthe encoding bits.* Fix doc tests* Shrink the size of `Amode`Reduces the size of `KnownOffset` so `Option&lt;KnownOffset&gt;` doesn&apos;t havesuch a high alignment or size, greatly shrinking the size of theinstruction and prevents the changes to `Div` from increasing the sizeof the overall `Inst` enum. In fact it now shrinks!* Don&apos;t model a trap code as an operand* Render trap information in `Display`

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Thu, 22 May 2025 15:51:40 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>61eb16de - Minor optimizations to assembler-generated code (#10811)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#61eb16de</link>
        <description>Minor optimizations to assembler-generated code (#10811)* Minor optimizations to assembler-generated codeThis is a few minor changes in the hopes of optimizing the compile-timeof the generated code itself for the x64 assembler crate, including:* Add `derive(Copy)` to all instructions to benefit from a specialized  implementation of `derive(Clone)` when a `Copy` implementation is also  present (e.g. it&apos;s `*foo` instead of a structural `clone`-each-field).* Don&apos;t use `write!` in `Display for Inst` and instead delegate directly  with methods to avoid formatting machinery.* Use helper methods in `RegisterVisitor` trait to have register  allocation be a method-per-operand and shrink the methods a bit.* Fix clippy warnings

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Tue, 20 May 2025 12:29:07 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>d9468c6e - asm: implement write-only operands (#10759)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#d9468c6e</link>
        <description>asm: implement write-only operands (#10759)* asm: implement write-only operandsThis change adds support to the new assembler for write-only operands.This implementation appeared first in [#10754] but is split out here tounblock implementation of instructions that require it: multiplication,conversions, moves, etc. This starts roughly the same as what wasimplemented for write-only XMMs in [#10754] but includes support forwrite-only GPRs as well and generates the temporary registers which areneeded.[#10754]: https://github.com/bytecodealliance/wasmtime/pull/10754Co-authored-by: Johnnie Birch &lt;johnnie.l.birch.jr@intel.com&gt;* fix: use `to_reg()` to extract the Cranelift type from `Writable`---------Co-authored-by: Johnnie Birch &lt;johnnie.l.birch.jr@intel.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Fri, 09 May 2025 21:58:03 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>5f3aefa1 - asm: plumb fixed registers through operand visitor (#10644)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#5f3aefa1</link>
        <description>asm: plumb fixed registers through operand visitor (#10644)* asm: plumb fixed registers through operand visitorThis finishes plumbing out fixed registers using the visitor pattern in`cranelift-codegen`. This was skipped initially in [#10629] because[#10632] offered a different approach; while we discuss whether and howthat should proceed, this change at least fixes up the current state ofthings.[#10629]: https://github.com/bytecodealliance/wasmtime/pull/10629[#10632]: https://github.com/bytecodealliance/wasmtime/pull/10632* Refactor visitor-related codegenThis simplifies and clarifies several parts related to emitting `visit`functions for assembler instructions.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Tue, 22 Apr 2025 21:33:41 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>6ad0840d - asm: allow printing of virtual registers (#10389)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#6ad0840d</link>
        <description>asm: allow printing of virtual registers (#10389)* Rename module: `reg` to `gpr`* Override `to_string` implementation for `cranelift-codegen` types* Add pretty-printing tests

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Fri, 14 Mar 2025 14:50:27 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>e33c4269 - asm: sse orpd implementation (#10273)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#e33c4269</link>
        <description>asm: sse orpd implementation (#10273)* sse orpd implementationassembler integration with isleformatadd clippy reason, reorder avx priority in islebless tests for orpdcreate separate xmm modulevalidate function rewrite sse conditionadd quote from manual for sse prefixformat changesmove Xmm bits under Reg* use new isle constructors for sse* remove unused function* minor changes

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Sat, 01 Mar 2025 06:49:48 +0000</pubDate>
        <dc:creator>Rahul &lt;rahul.s.chaphalkar@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>d7d605c2 - asm: re-allow prop-testing with `cargo test` (#10185)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#d7d605c2</link>
        <description>asm: re-allow prop-testing with `cargo test` (#10185)In #10110, I originally intended to use `arbitrary` implementations intwo ways: for long-running fuzz testing (e.g., with OSS-Fuzz) but alsofor quick property testing with `cargo test`. This latter use case couldreplace the tedious emit tests we had to write in `cranelift-codegen`_and_ find corner cases that we otherwise might not explore. It helpedme during development: just run `cargo test` to check if anything isobviously wrong. `arbtest` seemed to be able to run ~1000 test cases andfound mistakes well within the one second time limit I gave it.@alexcrichton improved #10110 by avoiding `Arbitrary` implementationseverywhere and unconditionally depending on the `arbitrary` crate. Thiswas the right change, but it removed the ability to property test using`cargo test`. What this change does is retain the general intent of hischange (no extra dependencies) but add `Arbitrary` implementations for`cfg(test)` as well to run property tests during `cargo test`.The only downside I see here is the added complexity when conditionallycompiling the fuzz-related bits: `#[cfg(any(test, feature = &quot;fuzz&quot;))]`.Perhaps there is a better way to do this, but this seemed to work fine.Let me know what you think.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Wed, 05 Feb 2025 16:00:53 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>0e056008 - asm: introduce a new x64 assembler (#10110)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs#0e056008</link>
        <description>asm: introduce a new x64 assembler (#10110)* asm: add initial infrastructure for an external assemblerThis change adds some initial logic implementing an external assemblerfor Cranelift&apos;s x64 backend, as proposed in RFC [#41].This adds two crates:- the `cranelift/assembler/meta` crate defines the instructions; to  print out the defined instructions use `cargo run -p  cranelift-assembler-meta`- the `cranelift/assembler` crate exposes the generated Rust code for  those instructions; to see the path to the generated code use `cargo  run -p cranelift-assembler`The assembler itself is straight-forward enough (modulo the codegeneration, of course); its integration into `cranelift-codegen` is whatis most tricky about this change. Instructions that we will emit in thenew assembler are contained in the `Inst::External` variant. Thisunfortunately increases the memory size of `Inst`, but only temporarilyif we end up removing the extra `enum` indirection by adopting the newassembler wholesale. Another integration point is ISLE: we generate ISLEdefinitions and a Rust helper macro to make the external assemblerinstructions accessible to ISLE lowering.This change introduces some duplication: the encoding logic (e.g. forREX instructions) currently lives both in `cranelift-codegen` and thenew assembler crate. The `Formatter` logic for the assembler `meta`crate is quite similar to the other `meta` crate. This minimalduplication felt worth the additional safety provided by the newassembler.The `cranelift-assembler` crate is fuzzable (see the `README.md`). Itwill generate instructions with randomized operands and compare theirencoding and pretty-printed string to a known-good disassembler,currently `capstone`. This gives us confidence we previously didn&apos;t haveregarding emission. In the future, we may want to think through how tofuzz (or otherwise check) the integration between `cranelift-codegen`and this new assembler level.[#41]: https://github.com/bytecodealliance/rfcs/pull/41* asm: bless Cranelift file testsUsing the new assembler&apos;s pretty-printing results in slightly differentdisassembly of compiled CLIF. This is because the assembler matches acertain configuration of `capstone`, causing the following obviousdifferences:- instructions with only two operands only print two operands; the  original `MInst` instructions separate out the read-write operand into  two separate operands (SSA-like)- the original instructions have some space padding after the  instruction mnemonic, those from the new assembler do notThis change uses the slightly new style as-is, but this is open fordebate; we can change the configuration of `capstone` that we fuzzagainst. My only preferences would be to (1) retain some way to visuallydistinguish the new assembler instructions in the disassembly(temporarily, for debugging) and (2) eventually transition topretty-printing instructions in Intel-style (`rw, r`) instead of thecurrent (`r, rw`).* ci: skip formatting when `rustfmt` not presentThough it is likely that `rustfmt` is present in a Rust environment,some CI tasks do not have this tool installed. To handle this case(plus the chance that other Wasmtime builds are similar), this changeskips formatting with a `stderr` warning when `rustfmt` fails.* vet: audit `arbtest` for use as a dev-dependency* ci: make assembler crates publishableIn order to satisfy `ci/publish.rs`, it would appear that we need to usea version that matches the rest of the Cranelift crates.* review: use Cargo workspace values* review: document `Inst`, move `Inst::name`* review: clarify &apos;earlier&apos; doc comment* review: document multi-byte opcodes* review: document `Rex` builder methods* review: document encoding rules* review: clarify &apos;bits&apos; -&gt; &apos;width&apos;* review: clarify confusing legacy prefixes* review: tweak IA-32e language* review: expand documentation for format* review: move feature list closer to enum* review: add a TODO to remove AT&amp;T operand ordering* review: move prefix emission to separate lines* review: add testing note* review: fix incomplete sentence* review: rename `MinusRsp` to `NonRspGpr`* review: add TODO for commented out instructions* review: add conservative down-conversion to `is_imm*`* Fuzzing updates for cranelift-assembler-x64 (#10)* Fuzzing updates for cranelift-assembler-x64* Ensure fuzzers build on CI* Move fuzz crate into the main workspace* Move `fuzz.rs` support code directly into fuzzer* Move `capstone` dependency into the fuzzer* Make `arbitrary` an optional dependencyShuffle around a few things in a few locations for this.* vet: skip audit for `cranelift-assembler-x64-fuzz`Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;* review: use 32-bit form for 8-bit and 16-bit reg-regCranelift&apos;s existing lowering for 8-bit and 16-bit reg-reg `AND` usedthe wider version of the instruction--the 32-bit reg-reg `AND`. Aspointed out by @cfallin [here], this was likely due to avoid partialregister stalls. This change keeps that lowering by distinguishing moreprecisely between `GprMemImm` that are in register or memory.[here]: https://github.com/bytecodealliance/wasmtime/pull/10110#discussion_r1939822255* fix: skip `rustfmt` on generated code in more casesApparently `rustfmt` is not found on the `x86_64-unknown-illumos` build.This change skips the action in this new case.prtest:full* fix: feed Cargo the meta crate versionThis fixes errors with the `publish.rs` script.prtest:full---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/api.rs</description>
        <pubDate>Mon, 03 Feb 2025 23:59:11 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
</channel>
</rss>
