en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#0889323a 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/condcodes.rs Sat, 03 Jan 2026 00:54:48 +0000 SSD <96286755+the-ssd@users.noreply.github.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#9ec02f9d 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/condcodes.rs Tue, 29 Aug 2023 16:02:06 +0000 Christopher Serr <christopher.serr@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#056ccdec Rename cc helpers (#6862)* Rename "reverse" to "flip"* Rename "inverse" to "negate"* Correct grammar in comment: change "an" to "a"* Rename "flip" to "swap_args"* Rename "negate" to "complement" List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Thu, 24 Aug 2023 05:05:06 +0000 Gurinder Singh <frederick.the.fool@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#81545c3a Revert "simple_gvn: recognize commutative operators (#6135)" (#6142)This reverts commit c85bf27ff8cdaffec26a25d46b4343a06e00027a. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Tue, 04 Apr 2023 20:22:44 +0000 Jamey Sharp <jsharp@fastly.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#c85bf27f simple_gvn: recognize commutative operators (#6135)* simple_gvn: recognize commutative operatorsNormalize instructions with commutative opcodes by sorting the arguments. Thismeans instructions like `iadd v0, v1` and `iadd v1, v0` will be consideredidentical by GVN and deduplicated.* Remove `UsubSat` and `SsubSat` from `is_commutative`They are not actually commutative* Remove `TODO`s* Move InstructionData normalization into helper fn* Add normalization of commutative instructions in the epgrah implementation* Handle reflexive icmp/fcmps in GVN* Change formatting of `normalize_in_place`* suggestions from code review List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Tue, 04 Apr 2023 00:25:05 +0000 Karl Meakin <karlwfmeakin@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#3d6d49da cranelift: Remove of/nof overflow flags from icmp (#4879)* cranelift: Remove of/nof overflow flags from icmp Neither Wasmtime nor cg-clif use these flags under any circumstances. From discussion on #3060 I see it's long been unclear what purpose these flags served. Fixes #3060, fixes #4406, and fixes #4875... by deleting all the code that could have been buggy. This changes the cranelift-fuzzgen input format by removing some IntCC options, so I've gone ahead and enabled I128 icmp tests at the same time. Since only the of/nof cases were failing before, I expect these to work. * Restore trapif tests It's still useful to validate that iadd_ifcout's iflags result can be forwarded correctly to trapif, and for that purpose it doesn't really matter what condition code is checked. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Wed, 07 Sep 2022 15:38:41 +0000 Jamey Sharp <jsharp@fastly.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#0f944937 cranelift: Fuzz `icmp` and `fcmp` (#4713)* cranelift: Add `fcmp` to fuzzer * cranelift: Add IntCC::all() * cranelift: Add `icmp` to fuzzer List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Mon, 15 Aug 2022 23:16:50 +0000 Afonso Bordado <afonso360@users.noreply.github.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#2b89b13c Move condcodes from cranelift-codegen-shared to cranelift-codegen List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Sun, 10 Oct 2021 12:23:26 +0000 bjorn3 <bjorn3@users.noreply.github.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs#747ad3c4 moved crates in lib/ to src/, renamed crates, modified some files' text (#660)moved crates in lib/ to src/, renamed crates, modified some files' text (#660) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/condcodes.rs Mon, 28 Jan 2019 23:56:54 +0000 lazypassion <25536767+lazypassion@users.noreply.github.com>