Changes in constant.rs

0889323a - cranelift-codegen: rename most uses of std to core and alloc (#12237)

Sat, 03 Jan 2026 00:54:48 +0000

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/ir/constant.rs

8a42768f - Update nightly used in CI (#10957)

Fri, 06 Jun 2025 18:06:28 +0000

Update nightly used in CI (#10957)A new lint was added to rustc so this updates the nightly used in CI andthen additionally fixes the lints that are firing. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it'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/ir/constant.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

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/ir/constant.rs

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

Wed, 17 Jul 2024 16:39:47 +0000

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/ir/constant.rs

d38d387a - Fix rustdoc warnings on Nightly (#8258)

Thu, 28 Mar 2024 19:19:22 +0000

Fix rustdoc warnings on Nightly (#8258)* Fix rustdoc warnings on NightlyI noticed during a failed doc build of another PR we've got a number ofwarnings being emitted, so resolve all those here.* Fix more warnings* Fix rebase conflicts List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

9ec02f9d - Decouple `serde` from its `derive` crate (#6917)

Tue, 29 Aug 2023 16:02:06 +0000

Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

8a9b1a90 - Implement an incremental compilation cache for Cranelift (#4551)

Fri, 12 Aug 2022 16:47:43 +0000

Implement an incremental compilation cache for Cranelift (#4551)This is the implementation of https://github.com/bytecodealliance/wasmtime/issues/4155, using the "inverted API" approach suggested by @cfallin (thanks!) in Cranelift, and trait object to provide a backend for an all-included experience in Wasmtime. After the suggestion of Chris, `Function` has been split into mostly two parts: - on the one hand, `FunctionStencil` contains all the fields required during compilation, and that act as a compilation cache key: if two function stencils are the same, then the result of their compilation (`CompiledCodeBase`) will be the same. This makes caching trivial, as the only thing to cache is the `FunctionStencil`. - on the other hand, `FunctionParameters` contain the... function parameters that are required to finalize the result of compilation into a `CompiledCode` (aka `CompiledCodeBase`) with proper final relocations etc., by applying fixups and so on. Most changes are here to accomodate those requirements, in particular that `FunctionStencil` should be `Hash`able to be used as a key in the cache: - most source locations are now relative to a base source location in the function, and as such they're encoded as `RelSourceLoc` in the `FunctionStencil`. This required changes so that there's no need to explicitly mark a `SourceLoc` as the base source location, it's automatically detected instead the first time a non-default `SourceLoc` is set. - user-defined external names in the `FunctionStencil` (aka before this patch `ExternalName::User { namespace, index }`) are now references into an external table of `UserExternalNameRef -> UserExternalName`, present in the `FunctionParameters`, and must be explicitly declared using `Function::declare_imported_user_function`. - some refactorings have been made for function names: - `ExternalName` was used as the type for a `Function`'s name; while it thus allowed `ExternalName::Libcall` in this place, this would have been quite confusing to use it there. Instead, a new enum `UserFuncName` is introduced for this name, that's either a user-defined function name (the above `UserExternalName`) or a test case name. - The future of `ExternalName` is likely to become a full reference into the `FunctionParameters`'s mapping, instead of being "either a handle for user-defined external names, or the thing itself for other variants". I'm running out of time to do this, and this is not trivial as it implies touching ISLE which I'm less familiar with. The cache computes a sha256 hash of the `FunctionStencil`, and uses this as the cache key. No equality check (using `PartialEq`) is performed in addition to the hash being the same, as we hope that this is sufficient data to avoid collisions. A basic fuzz target has been introduced that tries to do the bare minimum: - check that a function successfully compiled and cached will be also successfully reloaded from the cache, and returns the exact same function. - check that a trivial modification in the external mapping of `UserExternalNameRef -> UserExternalName` hits the cache, and that other modifications don't hit the cache. - This last check is less efficient and less likely to happen, so probably should be rethought a bit. Thanks to both @alexcrichton and @cfallin for your very useful feedback on Zulip. Some numbers show that for a large wasm module we're using internally, this is a 20% compile-time speedup, because so many `FunctionStencil`s are the same, even within a single module. For a group of modules that have a lot of code in common, we get hit rates up to 70% when they're used together. When a single function changes in a wasm module, every other function is reloaded; that's still slower than I expect (between 10% and 50% of the overall compile time), so there's likely room for improvement. Fixes #4155. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

80709ab6 - Rustfmt

Sun, 10 Oct 2021 13:26:43 +0000

Rustfmt List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

355dd996 - Fix tests

Sun, 10 Oct 2021 13:00:25 +0000

Fix tests List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

aa0486eb - Remove offset fields from ConstantPool

Sun, 10 Oct 2021 12:47:53 +0000

Remove offset fields from ConstantPool List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

2fc964ea - Add serde serialization support for the full clif ir

Sat, 19 Dec 2020 15:32:46 +0000

Add serde serialization support for the full clif ir List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

ce44719e - refactor: change LowerCtx::get_immediate to return a DataValue

Thu, 01 Oct 2020 17:33:49 +0000

refactor: change LowerCtx::get_immediate to return a DataValueThis change abstracts away (from the perspective of the new backend) how immediate values are stored in InstructionData. It gathers large immediates from necessary places (e.g. constant pool) and delegates to `InstructionData::imm_value` for the rest. This refactor only touches original users of `LowerCtx::get_immediate` but a future change could do the same for any place the new backend is accessing InstructionData directly to retrieve immediates. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

85ffc8f5 - Switch CI back to nightly channel (#2014)

Mon, 13 Jul 2020 23:40:47 +0000

Switch CI back to nightly channel (#2014)* Switch CI back to nightly channel I think all upstream issues are now fixed so we should be good to switch back to nightly from our previously pinned version. * Fix doc warnings List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

0672d1dc - Declare constants in the function preamble

Fri, 20 Mar 2020 21:08:03 +0000

Declare constants in the function preambleThis allows us to give names to constants in the constant pool and then use these names in the function body. The original behavior, specifiying the constant value as an instruction immediate, is still supported as a shortcut but some filetests had to change since the canonical way of printing the CLIF constants is now in the preamble. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

96f5a6b5 - Fix documentation link issues

Thu, 31 Oct 2019 16:17:27 +0000

Fix documentation link issues List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

9f506692 - Fix clippy warnings.

Thu, 24 Oct 2019 06:15:42 +0000

Fix clippy warnings.This commit fixes the current set of (stable) clippy warnings in the repo. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

67733bd2 - Use ConstantData exclusively for inserting data into the constant pool

Fri, 11 Oct 2019 16:26:08 +0000

Use ConstantData exclusively for inserting data into the constant poolPreviously we allowed anything that could be converted into ConstantData (e.g. a Vec). List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs

a03f905d - Replace V128Imm functionality with ConstantData

Wed, 02 Oct 2019 03:13:17 +0000

Replace V128Imm functionality with ConstantDataThis moves most original uses of V128Imm (e.g. in parsing) to ConstantData and shifts the unit tests from V128Imm to ConstantData. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/constant.rs