profile
viewpoint

bytecodealliance/wasmtime 3523

Standalone JIT-style runtime for WebAssembly, using Cranelift

bytecodealliance/cranelift 2481

Cranelift code generator

bytecodealliance/wasmparser 176

A simple event-driven library for parsing WebAssembly binary files

fitzgen/bindgen-tutorial-bzip2-sys 45

A tutorial/example crate for generating C/C++ bindings on-the-fly with libbindgen

CraneStation/wasmtime-wasi 24

WASI suppport for wasmtime

fitzgen/associative-cache 9

A generic, fixed-size, associative cache

fitzgen/ada-scheme 5

Following along with Peter Michaux's Scheme from Scratch series (http://peter.michaux.ca/articles/scheme-from-scratch-introduction) in Ada

bytecodealliance/wasmtime-libfuzzer-corpus 4

libFuzzer corpus for our wasmtime fuzz targets

issue openedrust-fuzz/arbitrary

Generate collections via a "continuation byte" rather than reading a length

Rather than doing

let mut collection = Collection::new();
let n = u.arbitrary_len()?;
for _ in 0..n {
    collection.insert(u.arbitrary()?);
}

to create a collection, we should consider doing

let mut collection = Collection::new();
loop {
    let continue = u.arbitrary::<bool>();
    if !continue {
        break;
    }
    collection.insert(u.arbitrary()?);
}

This paper found this second approach to make test case reduction much more effective.

We might not want to do this for strings though, since the fuzzer likely has some smarts around utf-8 sequences that we might break.

Also, we might want to use the size hint to still put an upper limit on how many elements we parse.

created time in 6 hours

delete branch fitzgen/wasmtime

delete branch : enable-ref-types-by-default

delete time in 2 days

push eventbytecodealliance/wasmtime

Nick Fitzgerald

commit sha 94e4bad1e05967566f378a75bced933c1c123fae

Enable reference types and bulk memory operations by default

view details

Nick Fitzgerald

commit sha 5af47dc4cd33f04ed4b5fbf4ea36d5df559d2773

cranelift: Only emit stack maps when a function actually uses reference types This fix avoids a small slow down in scenarios where reference types are enabled but a given function doesn't actually use them. Fixes #1883

view details

Nick Fitzgerald

commit sha bf16b3373991fe8f7bb393c6ca1d88521f3f7bba

docs: Use Title Case for the Table of Contents

view details

Nick Fitzgerald

commit sha 47d3c8de52ed840cbd2c1a14f0b351edea66432a

docs: Better title formatting for the coding guidelines

view details

Nick Fitzgerald

commit sha 5647dcbb8f40bc341839ec2aa1786ca27ec05135

docs: Document and advertise our support for various Wasm proposals

view details

Nick Fitzgerald

commit sha ef13e80bcfba482a7d7081ba20b380fc29cc5322

docs: Add contributor docs for implementing and enabling new Wasm proposals

view details

Nick Fitzgerald

commit sha 5f36d7eab715f2d8d0134a9616f4ea058799fc96

Merge pull request #2118 from fitzgen/enable-ref-types-by-default Enable ref types and bulk memory operations by default

view details

push time in 2 days

issue closedbytecodealliance/wasmtime

Cranelift: `emit_stackmaps` should avoid walking the IR if the function doesn't use `r32` or `r64`

Enabling stack maps and GC safepoints adds another pass over the IR (emit_stackmaps) regardless whether the function in question actually uses reference types at all. One could imagine (especially with wasm-bindgen's "switch reference types into table indices at the boundaries" approach, that seems likely to be copied by C/C++) that many functions in a module don't use reference types. For these functions, that extra pass over the IR is a waste of time.

We could have a flag on functions that gets set if it uses reference types in any way (and then never gets unset when a particular reference type-using instruction is removed, so we don't have to precisely count them) and in emit_stackmaps, only walk the IR if the flag is set (and probably debug_assert! that it doesn't have any uses of reference types if the flag is not set).

This came up in https://github.com/bytecodealliance/wasmtime/pull/1832#discussion_r440456291 for Wasmtime.

closed time in 2 days

fitzgen

PR merged bytecodealliance/wasmtime

Enable ref types and bulk memory operations by default cranelift wasmtime:api

Both have spent a bit of time enabled in our fuzzers by default and we haven't run into any issues in a while. The one catch was the potential slowdown due to #1883, but

  • I measured and, while it did exist, it was on the order of milliseconds when dealing with a 270K wasm module, and
  • I've added a commit that fixes the slowdown (and is otherwise generally a tiny speed up by doing a little manual LICM that the compiler failed to do because of a trait method call).
+203 -54

8 comments

7 changed files

fitzgen

pr closed time in 2 days

pull request commentbytecodealliance/wasmtime

Enable ref types and bulk memory operations by default

@alexcrichton okay I added two new bits of docs:

  1. A table, similar to https://webassembly.org/roadmap/, documenting our wasm proposal support. This is intended to be mostly outward facing.

  2. A couple checklists for implementing and enabling-by-default new wasm proposals. These are intended to be developer/reviewer focused.

Want to take another look?

fitzgen

comment created time in 2 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 94e4bad1e05967566f378a75bced933c1c123fae

Enable reference types and bulk memory operations by default

view details

Nick Fitzgerald

commit sha 5af47dc4cd33f04ed4b5fbf4ea36d5df559d2773

cranelift: Only emit stack maps when a function actually uses reference types This fix avoids a small slow down in scenarios where reference types are enabled but a given function doesn't actually use them. Fixes #1883

view details

Nick Fitzgerald

commit sha bf16b3373991fe8f7bb393c6ca1d88521f3f7bba

docs: Use Title Case for the Table of Contents

view details

Nick Fitzgerald

commit sha 47d3c8de52ed840cbd2c1a14f0b351edea66432a

docs: Better title formatting for the coding guidelines

view details

Nick Fitzgerald

commit sha 5647dcbb8f40bc341839ec2aa1786ca27ec05135

docs: Document and advertise our support for various Wasm proposals

view details

Nick Fitzgerald

commit sha ef13e80bcfba482a7d7081ba20b380fc29cc5322

docs: Add contributor docs for implementing and enabling new Wasm proposals

view details

push time in 2 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 0c2daed69eaaf7c7aecbb6a2616bef98c5fe7421

Enable reference types and bulk memory operations by default

view details

Nick Fitzgerald

commit sha e0c014c1a0d1a9ebbc349b8e641ef69409e8b2f6

cranelift: Only emit stack maps when a function actually uses reference types This fix avoids a small slow down in scenarios where reference types are enabled but a given function doesn't actually use them. Fixes #1883

view details

push time in 2 days

pull request commentbytecodealliance/wasmtime

Enable ref types and bulk memory operations by default

This is a good point to bring up, thanks Alex. Once we find consensus on what is required here, we should probably document it in our contributing guide.


You proposed requirements sound good to me, but I would even expand the last point about fuzzing to include a review of the ways that we've exposed the feature to the fuzzers.

  • Is it just enabled in the "compile" fuzz target's config or did we write custom fuzz targets to explicitly exercise running (rather than just compiling) this feature?
  • Did we add seeds to our corpora that use the feature?
  • Generally, how confident are we that the fuzzers have actually exercised this stuff? (e.g. does introducing a panic on purpose to some corner case get caught by the fuzzer pretty quickly?)

In particular, if we aren't pretty confident about that last point, I don't think we are ready to turn the feature on by default yet.

According to these standards, I feel good about reference types, and okay about bulk memory. I think bulk memory could probably use more runtime testing, rather than just "can we compile modules that use it" testing. For reference types, we have specialized fuzz targets that actually run the modules, not just compile them.

fitzgen

comment created time in 2 days

Pull request review commentbytecodealliance/wasmtime

Making caching support optional in Wasmtime

 impl Config {     ///     /// By default cache configuration is not enabled or loaded.     ///+    /// This method is only available when the `cache` feature of this crate is+    /// enaled.+    ///     /// # Errors     ///     /// This method can fail due to any error that happens when loading the file     /// pointed to by `path` and attempting to load the cache configuration.     ///     /// [docs]: https://bytecodealliance.github.io/wasmtime/cli-cache.html+    #[cfg(feature = "cache")]

Make sure to also add

[package.metadata.docs.rs]
all-features = true

to the Cargo.toml so users actually see these docs.

alexcrichton

comment created time in 2 days

Pull request review commentbytecodealliance/wasmtime

Making caching support optional in Wasmtime

 impl Config {     ///     /// By default cache configuration is not enabled or loaded.     ///+    /// This method is only available when the `cache` feature of this crate is+    /// enaled.
    /// enabled.
alexcrichton

comment created time in 2 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 05bf9ea3f362849f4659ba6d5d04e9a8c82c4527

Rename "Stackmap" to "StackMap" And "stackmap" to "stack_map". This commit is purely mechanical.

view details

Nick Fitzgerald

commit sha 174159a552959f739546eca550de28520bee1172

Bump `wast` to version 22.0.0 in peepmatic crates

view details

Nick Fitzgerald

commit sha aad086899c59539e1a783e05b492a6d31941c306

peepmatic: Implement maximum nesting level in parser So that we don't blow the stack. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24705

view details

Nick Fitzgerald

commit sha fdbc9e351f7440e168be77f8a8188b8429479267

Merge pull request #2111 from fitzgen/rename-stackmap-to-stack-map Rename "Stackmap" to "StackMap"

view details

Nick Fitzgerald

commit sha 00de2a6ab609cc3765704d781063c79099312c71

Merge pull request #2110 from fitzgen/peepmatic-parse-nesting-depth Peepmatic: Implement maximum nesting level in parser

view details

Gabor Greif

commit sha 9aebca11ad7a16ab2fc4cc0e98b3def7f3a7c690

Don't GC DW_TAG_variant(_part), they are referenced (#2113) by their respective parents. See also #2105.

view details

Gabor Greif

commit sha a796d654678c76b60c637aa1a8d91f4c6682747e

test_debug_parse_expressions: improve expression! macro (#2104) Provide automatic translation to opcodes from DW_OP_* identifiers. They are looked up from gimli. Since DW_OP_WASM_location is not contained in gimli yet, we take care of manually translating it.

view details

Nick Fitzgerald

commit sha ef7e2656e8338e2fd296112eaa0cf69172f72762

Enable reference types and bulk memory operations by default

view details

Nick Fitzgerald

commit sha 9307e471c56da377c24a8d836041bf726f27ac51

cranelift: Only emit stack maps when a function actually uses reference types This fix avoids a small slow down in scenarios where reference types are enabled but a given function doesn't actually use them. Fixes #1883

view details

push time in 2 days

PR opened bytecodealliance/wasmtime

Reviewers
Enable ref types and bulk memory operations by default

Both have spent a bit of time enabled in our fuzzers by default and we haven't run into any issues in a while. The one catch was the potential slowdown due to #1883, but

  • I measured and, while it did exist, it was on the order of milliseconds when dealing with a 270K wasm module, and
  • I've added a commit that fixes the slowdown (and is otherwise generally a tiny speed up by doing a little manual LICM that the compiler failed to do because of a trait method call).
+28 -38

0 comment

2 changed files

pr created time in 2 days

create barnchfitzgen/wasmtime

branch : enable-ref-types-by-default

created branch time in 2 days

delete branch fitzgen/wasmtime

delete branch : peepmatic-parse-nesting-depth

delete time in 2 days

push eventbytecodealliance/wasmtime

Nick Fitzgerald

commit sha 174159a552959f739546eca550de28520bee1172

Bump `wast` to version 22.0.0 in peepmatic crates

view details

Nick Fitzgerald

commit sha aad086899c59539e1a783e05b492a6d31941c306

peepmatic: Implement maximum nesting level in parser So that we don't blow the stack. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24705

view details

Nick Fitzgerald

commit sha 00de2a6ab609cc3765704d781063c79099312c71

Merge pull request #2110 from fitzgen/peepmatic-parse-nesting-depth Peepmatic: Implement maximum nesting level in parser

view details

push time in 2 days

PR merged bytecodealliance/wasmtime

Peepmatic: Implement maximum nesting level in parser cranelift cranelift:area:peepmatic

Depends on https://github.com/bytecodealliance/wasm-tools/pull/75

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+24 -14

1 comment

7 changed files

fitzgen

pr closed time in 2 days

delete branch fitzgen/wasmtime

delete branch : rename-stackmap-to-stack-map

delete time in 2 days

push eventbytecodealliance/wasmtime

Nick Fitzgerald

commit sha 05bf9ea3f362849f4659ba6d5d04e9a8c82c4527

Rename "Stackmap" to "StackMap" And "stackmap" to "stack_map". This commit is purely mechanical.

view details

Nick Fitzgerald

commit sha fdbc9e351f7440e168be77f8a8188b8429479267

Merge pull request #2111 from fitzgen/rename-stackmap-to-stack-map Rename "Stackmap" to "StackMap"

view details

push time in 2 days

PR merged bytecodealliance/wasmtime

Rename "Stackmap" to "StackMap" cranelift cranelift:area:aarch64 cranelift:area:machinst cranelift:area:x64 cranelift:meta cranelift:module

And "stackmap" to "stack_map".

This commit is purely mechanical.

r? @cfallin

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+218 -211

1 comment

44 changed files

fitzgen

pr closed time in 2 days

push eventfitzgen/wasmtime

Johnnie Birch

commit sha 2eadc6e2a8b2ba1e56182b927dfe8e96adac6479

Add packed integer add opcodes (v128) to instruction set enum

view details

Johnnie Birch

commit sha dd6ba5f9d74dd84f9849708073b3dd542da7af7e

Lower packed integer add instructions (v128) Adds lowering support for packed integer add instructions and helper function for determining if a type for an instruction indicates it is packed.

view details

Johnnie Birch

commit sha f5909b37c367142ac5e9a6420a62d2a2c551e89b

Add emit tests for packed integer add instructions

view details

Johnnie Birch

commit sha e60a6f2ad2fca85afbd71840c8668919c330aed1

Fixup packed integer add lowering Remove stray print statement Fix bug in match statement causing unreachable code.

view details

Christopher Agia

commit sha 2482bd80c24a6b23ac1a259df77c61d5cc9c93a9

Caller get_export() implemented for Extern::Func. (#2108) * Caller get_export() implemented for func * update tests for get_export() Extern::Func return Signed-off-by: Christopher Agia <chrisagia@google.com> * document get_export() for Extern::Func Signed-off-by: Christopher Agia <chrisagia@google.com>

view details

Andrew Brown

commit sha f0e32c5f715a39b23407a7c0ee6f2ea9ef28788c

Fix typo (#2114)

view details

push time in 2 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 174159a552959f739546eca550de28520bee1172

Bump `wast` to version 22.0.0 in peepmatic crates

view details

Nick Fitzgerald

commit sha aad086899c59539e1a783e05b492a6d31941c306

peepmatic: Implement maximum nesting level in parser So that we don't blow the stack. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24705

view details

push time in 2 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 05bf9ea3f362849f4659ba6d5d04e9a8c82c4527

Rename "Stackmap" to "StackMap" And "stackmap" to "stack_map". This commit is purely mechanical.

view details

push time in 2 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha c7b009983e9361000abf7735126312f3da6ed6d4

Rename "Stackmap" to "StackMap" And "stackmap" to "stack_map". This commit is purely mechanical.

view details

push time in 3 days

PR opened bytecodealliance/wasmtime

Reviewers
Rename "Stackmap" to "StackMap"

And "stackmap" to "stack_map".

This commit is purely mechanical.

r? @cfallin

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+218 -218

0 comment

44 changed files

pr created time in 3 days

create barnchfitzgen/wasmtime

branch : rename-stackmap-to-stack-map

created branch time in 3 days

PR opened bytecodealliance/wasmtime

Reviewers
Peepmatic parse nesting depth

Depends on https://github.com/bytecodealliance/wasm-tools/pull/75

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+27 -15

0 comment

8 changed files

pr created time in 3 days

create barnchfitzgen/wasmtime

branch : peepmatic-parse-nesting-depth

created branch time in 3 days

create barnchfitzgen/wasm-tools

branch : parens-depth-public

created branch time in 3 days

push eventfitzgen/wasmtime

Chris Fallin

commit sha f9b98f0ddcfdf2d369f93d8c3d8492c7086d23ee

Aarch64 codegen quality: support more general add+extend computations. Previously, our pattern-matching for generating load/store addresses was somewhat limited. For example, it could not use a register-extend address mode to handle the following CLIF: ``` v2760 = uextend.i64 v985 v2761 = load.i64 notrap aligned readonly v1 v1018 = iadd v2761, v2760 store v1017, v1018 ``` This PR adds more general support for address expressions made up of additions and extensions. In particular, it pattern-matches a tree of 64-bit `iadd`s, optionally with `uextend`/`sextend` from 32-bit values at the leaves, to collect the list of all addends that form the address. It also collects all offsets at leaves, combining them. It applies a series of heuristics to make the best use of the available addressing modes, filling the load/store itself with as many 64-bit registers, zero/sign-extended 32-bit registers, and/or an offset, then computing the rest with add instructions as necessary. It attempts to make use of immediate forms (add-immediate or subtract-immediate) whenever possible, and also uses the built-in extend operators on add instructions when possible. There are certainly cases where this is not optimal (i.e., does not generate the strictly shortest sequence of instructions), but it should be good enough for most code. Using `perf stat` to measure instruction count (runtime only, on wasmtime, after populating the cache to avoid measuring compilation), this impacts `bz2` as follows: ``` pre: 1006.410425 task-clock (msec) # 1.000 CPUs utilized 113 context-switches # 0.112 K/sec 1 cpu-migrations # 0.001 K/sec 5,036 page-faults # 0.005 M/sec 3,221,547,476 cycles # 3.201 GHz 4,000,670,104 instructions # 1.24 insn per cycle <not supported> branches 27,958,613 branch-misses 1.006071348 seconds time elapsed post: 963.499525 task-clock (msec) # 0.997 CPUs utilized 117 context-switches # 0.121 K/sec 0 cpu-migrations # 0.000 K/sec 5,081 page-faults # 0.005 M/sec 3,039,687,673 cycles # 3.155 GHz 3,837,761,690 instructions # 1.26 insn per cycle <not supported> branches 28,254,585 branch-misses 0.966072682 seconds time elapsed ``` In other words, this reduces instruction count by 4.1% on `bz2`.

view details

Chris Fallin

commit sha 8fd92093a41368a36c052732401c8e9fd8911c5a

Merge pull request #2061 from cfallin/aarch64-amode Aarch64 codegen quality: support more general add+extend address computations.

view details

Benjamin Bouvier

commit sha 7f109a51987fa03f8fbacf80358cb40358c363d8

machinst x64: use a sign-extension when loading jump table offsets; The jump table offset that's loaded out of the jump table could be signed (if it's an offset to before the jump table itself), so we should use a signed extension there, not an unsigned extension.

view details

Benjamin Bouvier

commit sha 2c1d3704653f094a93848a87f79361bca511392b

CI: use fixed version of Rust nightly following build failures in staticvec

view details

Nick Fitzgerald

commit sha 71025e383dc44439bafbe4dc8db367208b4a3e2c

deps: Update libfuzzer-sys to 0.3.3 (#2072) This update gives us access to the new Entropic fuzzing engine: https://mboehme.github.io/paper/FSE20.Entropy.pdf

view details

Anton Kirilov

commit sha adf25d27c2cca3d1cb86584c07f370a7d7d62abb

AArch64: Implement SIMD floating-point arithmetic Copyright (c) 2020, Arm Limited.

view details

Chris Fallin

commit sha f8f79ba9cae3fd4d22791cba4bfceb08bed1438e

Merge pull request #2075 from akirilov-arm/simd_fp_arith AArch64: Implement SIMD floating-point arithmetic

view details

Daiki Ueno

commit sha e70f73211dc0db2e7432287695497eee397dd2a8

virtfs file: update cursor position on fd_read (#2070) * virtfs file: update cursor position on fd_read If a handle is backed by InMemoryFile, fd_read (turned into Handle::read_vectored) doesn't update the cursor position properly and thus prevents the caller from detecting EOF. * virtfs file: fd_{pread,pwrite}: update offset in iovec iteration If multiple iovec's are supplied, fd_pread and fd_pwrite previously access data at the same offset for each iovec.

view details

Alex Crichton

commit sha 39ea64140f7fb05b61d90fdae55ae279c7d2b8ed

Expand doc section about "what about `#![no_std]`?" (#2024) * Expand doc section about "what about `#![no_std]`?" This commit expands the `#![no_std]` section of the documentation with an FAQ-style set of words which explains in more detail about why we don't support `#![no_std]` at this time, and how we can support it in the future. * Review comments * Add some more words about -Zbuild-std

view details

Benjamin Bouvier

commit sha 79abcdb035769d1e34d6a4d5f81cbd5abd969695

machinst x64: add testing to the CI;

view details

Andrew Brown

commit sha dc6220b87caa84eefd92067b0f87ed90ade7c0ef

machinst x64: add uses for crate dependencies

view details

Andrew Brown

commit sha 77cc2f69c1736180643d1042a4b2a8558441109d

machinst x64: allow use of vector-length types

view details

Andrew Brown

commit sha e3bd8d696bc920e26d362bac4c0604c2c7484c64

machinst x64: add basic packed FP arithmetic Includes instruction definition of packed min/max.

view details

Andrew Brown

commit sha 0398033447385ee47956c0fa45cbc6a63379fe5e

machinst x64: add packed FP comparisons Re-orders the SseOpcode variants alphabetically.

view details

Andrew Brown

commit sha c74a9d122541bbf2440dd62911a1e23645579c58

machinst x64: add packed shifts

view details

Andrew Brown

commit sha eda5c6d37064e87834aff45389462b0101c07220

machinst x64: add packed FP negation

view details

Andrew Brown

commit sha 999fa00d6ae0847eafd1d43006eeb8218629b40d

machinst x64: add loading of inline 128-bit constants Eventually the `load + jmp + constant` pattern should be replaced with just `load` once constant pools are more tightly integrated.

view details

Andrew Brown

commit sha 0306f247273f796fb72f28cb28e1b4cad18627d7

machinst x64: enable initial SIMD spec tests

view details

Chris Fallin

commit sha 1fbdf169b577212e3ff0fa5024ff0bcaa35ec705

Aarch64: fix narrow integer-register extension with Baldrdash ABI. In the Baldrdash (SpiderMonkey) embedding, we must take care to zero-extend all function arguments to callees in integer registers when the types are narrower than 64 bits. This is because, unlike the native SysV ABI, the Baldrdash ABI expects high bits to be cleared. Not doing so leads to difficult-to-trace errors where high bits falsely tag an int32 as e.g. an object pointer, leading to potential security issues.

view details

Chris Fallin

commit sha dd098656111396afa58e90084a705744e836bf10

Fix MachBuffer branch handling with redirect chains. When one branch target label in a MachBuffer is redirected to another, we eventually fix up branches targetting the first to refer to the redirected target instead. Separately, we have a branch-folding optimization that, when an unconditional branch occurs as the only instruction in a block (right at a label) and the previous instruction is also an unconditional branch (hence no fallthrough), we can elide that block entirely and redirect the label. Finally, we prevented infinite loops when resolving label aliases by chasing only one alias deep. Unfortunately, these three facts interacted poorly, and this is a result of our correctness arguments assuming a fully-general "redirect" that was not limited to one indirection level. In particular, we could have some label A that redirected to B, then remove the block at B because it is just a single branch to C, redirecting B to C. A would still redirect to B, though, without chasing to C, and hence a branch to B would fall through to the unrelated block that came after block B. Thanks to @bnjbvr for finding this bug while debugging the x64 backend and reducing a failure to the function in issue #2082. (This is a very subtle bug and it seems to have been quite difficult to chase; my apologies!) The fix is to (i) chase redirects arbitrarily deep, but also (ii) ensure that we do not form a cycle of redirects. The latter is done by very carefully checking the existing fully-resolved target of the label we are about to redirect *to*; if it resolves back to the branch that is causing this redirect, then we avoid making the alias. The comments in this patch make a slightly more detailed argument why this should be correct. Unfortunately we cannot directly test the CLIF that @bnjbvr reduced because we don't have a way to assert anything about the machine-code that comes after the branch folding and emission. However, the dedicated unit tests in this patch replicate an equivalent folding case, and also test that we handle branch cycles properly (as argued above). Fixes #2082.

view details

push time in 3 days

pull request commentWebAssembly/website

Update features.json for Firefox 79

Well, teh support does exist in Beta 79 too, assuming it was correct before. Kinda confusing that it is in beta 79 but not stable 79 :-/

fitzgen

comment created time in 3 days

pull request commentWebAssembly/website

Update features.json for Firefox 79

I think the "Beta 79" prefix that it originally had can stay.

I don't see a flag in about:config either...

I am just basing this off of (a) the lack of SIMD mention in https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#WebAssembly and (b) when I open the roadmap page in Firefox 79 stable it has an X for SIMD in the "your browser" column.

It is possible that it did ride to stable, happened not to get mentioned in the release notes, and the wasm feature detection library has a bug, but seems fairly unlikely...

fitzgen

comment created time in 3 days

pull request commentWebAssembly/website

Update features.json for Firefox 79

Should I make a new PR?

fitzgen

comment created time in 3 days

pull request commentWebAssembly/website

Update features.json for Firefox 79

Aaaaaand it looks like this PR landed 34 seconds too soon :sweat_smile:

fitzgen

comment created time in 3 days

pull request commentWebAssembly/website

Update features.json for Firefox 79

Woops, I missed the version field. Fixed now!

@kripken

Oh nice, is SIMD enabled by default on x86/x86_64 now?

I thought so, but it looks like it actually didn't ride the train to stable. I've force pushed to update that

fitzgen

comment created time in 3 days

push eventfitzgen/website

Nick Fitzgerald

commit sha 199f6cc749a42932728a321c61586aaf841a343f

Update features.json for Firefox 79

view details

push time in 3 days

push eventfitzgen/website

Nick Fitzgerald

commit sha fd66d29031cb32ff91b48ae2f1ce4bdd37622d69

Update features.json for Firefox 79

view details

push time in 3 days

PR opened WebAssembly/website

Update features.json for Firefox 79

@RReverser, please take a look, thanks!

+3 -3

0 comment

1 changed file

pr created time in 3 days

create barnchfitzgen/website

branch : features-for-firefox-79

created branch time in 3 days

push eventbytecodealliance/wasm-tools

Alex Crichton

commit sha 58a4895d213b79c9f3f885c58ebed05370e90be6

Place a limit on the depth of recursive module parsing The entire `wast` crate is designed with recursive descent parsing in mind, since it's quite easy to work with at an API layer. The downside of this is that stack overflow happens on deeply recursive syntax. While we handle this for expressions with an explicit `Vec` and a stack, this would require a much larger refactoring to handle this for nested modules. This commit places a hardcoded limit on the depth of nested modules to prevent the parser from stack overflowing. The hope is that this won't ever get hit in practice, but if it does we can try to rearchitect at least the top-level module parsing to not be as recursive.

view details

Nick Fitzgerald

commit sha 3762911464dfa757477ea211620857730e316cb3

Merge pull request #74 from alexcrichton/less-recursion Place a limit on the depth of recursive module parsing

view details

push time in 3 days

PR merged bytecodealliance/wasm-tools

Place a limit on the depth of recursive module parsing

The entire wast crate is designed with recursive descent parsing in mind, since it's quite easy to work with at an API layer. The downside of this is that stack overflow happens on deeply recursive syntax. While we handle this for expressions with an explicit Vec and a stack, this would require a much larger refactoring to handle this for nested modules.

This commit places a hardcoded limit on the depth of nested modules to prevent the parser from stack overflowing. The hope is that this won't ever get hit in practice, but if it does we can try to rearchitect at least the top-level module parsing to not be as recursive.

+21 -0

0 comment

2 changed files

alexcrichton

pr closed time in 3 days

Pull request review commentbytecodealliance/regalloc.rs

Fix slowness in BT's coalescing analysis when some regs have very man…

 pub fn compute_reg_to_ranges_maps<F: Function>(     rlr_env: &TypedIxVec<RealRangeIx, RealRange>,     vlr_env: &TypedIxVec<VirtualRangeIx, VirtualRange>, ) -> RegToRangesMaps {+    // Arbitrary, but chosen after quite some profiling, so as to minimise both instruction+    // count and number of `malloc` calls.  Don't mess with this without first collecting+    // comprehensive measurements.  Note that if you set this above 255, the type of+    // `r/vreg_approx_frag_counts` below will need to change accordingly.+    const MANY_FRAGS_THRESH: u8 = 200;++    // Adds `to_add` to `*counter`, taking care not to overflow it in the process.+    let saturating_add = |counter: &mut u8, to_add: usize| {+        let mut n = *counter as usize;+        n += to_add as usize;+        if n > 0xFF {+            n = 0xFF;+        }+        *counter = n as u8;+    };

Is there a reason this is open coded instead of using std methods?

let to_add: u8 = to_add.try_into().unwrap_or(std::u8::MAX);
*counter = counter.saturating_add(to_add)
julian-seward1

comment created time in 3 days

push eventbytecodealliance/wasmtime

Alex Crichton

commit sha d6f64ec88efcf4a63188fe5597529767538ade41

Make spectest fuzzing more deterministic Currently spectest fuzzing indexes into a compile-time-created array of strings which is the list of input files, but the order of this array is dependent on the filesystem that we're reading from. This means that inputs from oss-fuzz may not be easily reproducible locally because files could be read in different orders, so indexes could be distinct. This commit instead reads the directory paths, then sorts them, then includes them for testing. That way fuzz inputs at a specific commit should be consistent.

view details

Nick Fitzgerald

commit sha 25808cda95e3e3f48c25342c44b3483f3c27f7b3

Merge pull request #2106 from alexcrichton/better-fuzzing Make spectest fuzzing more deterministic

view details

push time in 3 days

PR merged bytecodealliance/wasmtime

Make spectest fuzzing more deterministic fuzzing

Currently spectest fuzzing indexes into a compile-time-created array of strings which is the list of input files, but the order of this array is dependent on the filesystem that we're reading from. This means that inputs from oss-fuzz may not be easily reproducible locally because files could be read in different orders, so indexes could be distinct.

This commit instead reads the directory paths, then sorts them, then includes them for testing. That way fuzz inputs at a specific commit should be consistent.

+6 -3

1 comment

1 changed file

alexcrichton

pr closed time in 3 days

pull request commentbytecodealliance/wasmtime

Fix Wasm translator to handle loop parameters on br_table default target.

Yeah, I've generally had a better experience running creduce on the WAT than running wasm-reduce on the Wasm.

cfallin

comment created time in 4 days

Pull request review commentbytecodealliance/wasm-tools

Initial implementation of memory64 proposal

 impl<'a> BinaryReader<'a> {         Ok(result)     } +    /// Advances the `BinaryReader` up to four bytes to parse a variable+    /// length integer as a `u64`.+    /// # Errors+    /// If `BinaryReader` has less than one or up to four bytes remaining, or
    /// length integer as a `u64`.
    ///
    /// # Errors
    ///
    /// If `BinaryReader` has less than one or up to four bytes remaining, or
alexcrichton

comment created time in 5 days

Pull request review commentbytecodealliance/wasm-tools

Initial implementation of memory64 proposal

 pub struct ResizableLimits {     pub maximum: Option<u32>, } +#[derive(Debug, Copy, Clone, PartialEq, Eq)]+pub struct ResizableLimits64 {+    pub initial: u64,+    pub maximum: Option<u64>,+}+ #[derive(Debug, Copy, Clone, PartialEq, Eq)] pub struct TableType {     pub element_type: Type,     pub limits: ResizableLimits, }  #[derive(Debug, Copy, Clone, PartialEq, Eq)]-pub struct MemoryType {-    pub limits: ResizableLimits,-    pub shared: bool,+pub enum MemoryType {+    B32 {

What is "B" here? Not that it matters much, but I guess I would expect "Memory" or simply "M".

alexcrichton

comment created time in 5 days

Pull request review commentbytecodealliance/wasm-tools

Implement the multi-memory proposal

 impl<'a> Parse<'a> for TableArg<'a> {     } } +/// Extra data associated with unary memory instructions.+#[derive(Debug)]+pub struct MemoryArg<'a> {+    /// The index of the table argument.
    /// The index of the memory space.
alexcrichton

comment created time in 6 days

Pull request review commentbytecodealliance/wasmtime

clif-util: only print color escape sequences in verbose mode

 fn add_verbose_flag<'a>() -> clap::Arg<'a, 'a> {     Arg::with_name("verbose").short("v").help("Be more verbose") } +arg_enum! {+    #[derive(Clone, Copy, Debug, PartialEq)]+    pub enum UseTerminalColor {+        Yes,+        No,+        Always

I just checked with git and their options are always|never|auto. I think it is worth being consistent with that, since people are more likely used to their options than something we make up ourselves. sorry for getting it wrong initially!

abrown

comment created time in 6 days

push eventrust-lang/rust-bindgen

Travis CI

commit sha e9188fe8431e46ea0386b13666d73b8a43655db5

Rebuild users guide at ff36981

view details

push time in 6 days

issue openedrust-lang/cargo

Support glob patterns for crate arguments to --package and --exclude flags

<!-- Thanks for filing a 🙋 feature request 😄! -->

Describe the problem you are trying to solve

In workspaces where there are many crates, I would like to only build/test the crates that share the "peepmatic-" name prefix. Or I would like to exclude all of the crates with the "wasmtime-" name prefix.

Describe the solution you'd like <!-- A clear and concise description of what you want to happen. -->

Support glob-style * wildcards for the -p/--package and --exclude flags when building in a workspace, like

$ cargo build --exclude peepmatic-*

Notes <!-- Any additional context or information you feel may be relevant to the issue. -->

Would help cut down on monstrosities like this:

        cargo +nightly \
            -Zfeatures=all -Zpackage-features \
            test \
            --features test-programs/test_programs \
            --features experimental_x64 \
            --all \
            --exclude lightbeam \
            --exclude peepmatic \
            --exclude peepmatic-automata \
            --exclude peepmatic-fuzzing \
            --exclude peepmatic-macro \
            --exclude peepmatic-runtime \
            --exclude peepmatic-test

We could collapse all those excludes into just --exlude lightbeam --exclude peepmatic*.

created time in 6 days

issue openedrust-fuzz/arbitrary

Revisit making `String`'s `Arbitrary` implementation fallible

At least during test case reduction, it would be better to use from_utf8_lossy, because we would rather have some replacement chars in a smaller string than fail to generate a Self.

Possibly we could set an environment variable from cargo fuzz tmin that changes this behavior, if we still want test case generation to be fallible rather than use replacement chars.

cc @Manishearth

created time in 6 days

issue commentprove-rs/z3.rs

z3-sys fails to build on Windows?

Thanks for filing an issue.

I have to admit that I'm not super familiar with either windows or cmake. I basically have just done enough to get it building in CI, and that pushed me to the limits of my windows/cmake knowledge.

I do see an "Access is denied." message in there, maybe it is a directory permissions thing?

If you or anyone else can help resolve this, that would be very appreciated!

zkat

comment created time in 6 days

push eventprove-rs/z3.rs

Jason Shirk

commit sha fea3d432d5b674e341592585163c1ec38ff18497

Enable parallel build of static lib on Windows

view details

Nick Fitzgerald

commit sha 8f911b153fb1196ba3d9a6d70989fb5f922f92ce

Merge pull request #86 from lzybkr/parallel_build Enable parallel build of static lib on Windows

view details

push time in 6 days

PR merged prove-rs/z3.rs

Enable parallel build of static lib on Windows

Closes #82

+5 -0

0 comment

1 changed file

lzybkr

pr closed time in 6 days

issue closedprove-rs/z3.rs

Static-link-z3 build should be parallelized

The static link build is pretty slow.

On Windows, the simplest thing is to add

        cfg.cxxflag("-MP");

This is a huge win on my 32 core build machine - going from I don't even know how long (30 minutes?) to around 7 minutes.

An incremental improvement is to also build in parallel with msbuild:

    cfg.build_arg("-m");

This shaved another 2 minutes off the build, maybe it could be improved even better as I'm sure there was some contention over cores, but maybe it's good enough.

I tried setting NUM_JOBS to get cmake to add -m automatically but for whatever reason it didn't seem to work for me.

Would a Windows only PR be welcome?

closed time in 6 days

lzybkr

startedgamozolabs/fzero_fuzzer

started time in 11 days

PR opened bytecodealliance/wasmtime

Reviewers
deps: Update libfuzzer-sys to 0.3.3

This update gives us access to the new Entropic fuzzing engine: https://mboehme.github.io/paper/FSE20.Entropy.pdf

<!--

Please ensure that the following steps are all taken care of before submitting the PR.

  • [ ] This has been discussed in issue #..., or if not, please tell us why here.
  • [ ] A short description of what this does, why it is needed; if the description becomes long, the matter should probably be discussed in an issue first.
  • [ ] This PR contains test cases, if meaningful.
  • [ ] A reviewer from the core maintainer team has been assigned for this PR. If you don't know who could review this, please indicate so. The list of suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct. -->

+3 -3

0 comment

2 changed files

pr created time in 13 days

create barnchfitzgen/wasmtime

branch : update-libfuzzer-sys-to-0.3.3

created branch time in 13 days

push eventfitzgen/wasmtime

Nick Fitzgerald

commit sha 2efb46afd519fb5595a36b4244d592acd61873cc

wasmtime-c-api: Add `wasmtime_store_gc` for GCing `externref`s

view details

Nick Fitzgerald

commit sha 56c517d2654c6fa614f231295aa0668989ccb098

examples: Add a GC call to the externref C example

view details

Nick Fitzgerald

commit sha 17b99cc9c897a5ea3204eba711d94acc3d198780

examples: Add a GC call to the externref Rust example

view details

Nick Fitzgerald

commit sha c420f65214aa3dc41eee25f8ae6c2b8f5f54dff9

Merge pull request #2052 from fitzgen/gc-function-in-c-api Add a GC function to the C API

view details

Yury Delendik

commit sha 399ee0a54c3be0f89ae07a0af5104ba929a9eba4

Serialize and deserialize compilation artifacts. (#2020) * Serialize and deserialize Module * Use bincode to serialize * Add wasm_module_serialize; docs * Simple tests

view details

Anton Kirilov

commit sha 420c4f06b892ea4f0f37c965e6e845ed6c6842af

AArch64: Improve code generation for Extractlane + Sextend / Uextend Copyright (c) 2020, Arm Limited.

view details

Joey Gouly

commit sha 5355c3e3d52e506d83724fa10ead7dd9213f83b3

arm64: Implement Vselect opcode This is implemented the same as Bitselect, as the controlling vector is a boolean vector. A boolean vector in cranelift has elements that are either 0 or all 1s, so it can be used to select elements lane wise. Copyright (c) 2020, Arm Limited.

view details

Alex Crichton

commit sha 8a04fc3cdc481e458871cec939eadc07c436003f

Refactor wasmtime's internal cache slightly (#2057) Be more generic over the type being serialized, and remove an intermediate struct which was only used for serialization but isn't necessary.

view details

Chris Fallin

commit sha b8f6d53a6bdf861e66093a046a081c886546cdf1

Aarch64 codegen: represent bool `true` as -1, not 1. It seems that this is actually the correct behavior for bool types wider than `b1`; some of the vector instruction optimizations depend on bool lanes representing false and true as all-zeroes and all-ones respectively. For `b8`..`b64`, this results in an extra negation after a `cset` when a bool is produced by an `icmp`/`fcmp`, but the most common case (`b1`) is unaffected, because an all-ones one-bit value is just `1`. An example of this assumption can be seen here: https://github.com/bytecodealliance/wasmtime/blob/399ee0a54c3be0f89ae07a0af5104ba929a9eba4/cranelift/codegen/src/simple_preopt.rs#L956 Thanks to Joey Gouly of ARM for noting this issue while implementing SIMD support, and digging into the source (finding the above example) to determine the correct behavior.

view details

Chris Fallin

commit sha d22cefd220cb2b679e8363b7fb7f9f9d758905ac

Merge pull request #2058 from cfallin/aarch64-fix-bool Aarch64 codegen: represent bool `true` as -1, not 1.

view details

Chris Fallin

commit sha 44ef8247a962eda7653e0304b5acd281dc92c462

Merge pull request #2062 from akirilov-arm/extract_lane AArch64: Improve code generation for Extractlane + Sextend / Uextend

view details

Chris Fallin

commit sha 87eb4392c4829c559f5e142b1b58b8bbf6d05555

Merge pull request #2063 from jgouly/vselect arm64: Implement Vselect opcode

view details

Chris Fallin

commit sha 2b9fefe89a232bad2c7d209c49cf9b583719a763

Add timing for several new-backend stages. This PR adds a bit more granularity to the output of e.g. `clif-util compile -T`, indicating how much time is spent in VCode lowering and various other new-backend-specific tasks.

view details

Yury Delendik

commit sha 42127aac4e974dd6aaf8dfe553d60fa0bcf069dd

Refactor Cache logic to include debug information (#2065) * move caching to the CompilationArtifacts * mv cache_config from Compiler to CompiledModule * hash isa flags * no cache for wasm2obj * mv caching to wasmtime crate * account each Compiler field when hash

view details

Chris Fallin

commit sha 37a09c4ef685a1255fcb6cc4eb379876272a833c

Merge pull request #2066 from cfallin/machinst-timing Add timing for several new-backend stages.

view details

Benjamin Bouvier

commit sha cd54f05efd2c30da625ef27e173323f3a5ee6321

machinst x64: implement float-to-int and int-to-float conversions;

view details

Benjamin Bouvier

commit sha e43310a088aceaa46fbdc810e15a85f6dee10806

machinst x64: adapt conversions for saturation behaviors;

view details

Benjamin Bouvier

commit sha 03b9e1e86a26a788faa4fca627971d20d2a3c353

machinst x64: implement float min/max with the right semantics;

view details

Benjamin Bouvier

commit sha 48ec806a9dd8390b1996da84a0f2cfa976918e9d

machinst x64: implement Fabs/Fneg in terms of other instructions;

view details

Benjamin Bouvier

commit sha 694af3aec20a80310766bab7a16a5b6b9b2422e1

machinst x64: implement float Floor/Ceil/Trunc/Nearest as VM calls;

view details

push time in 13 days

pull request commentrust-fuzz/libfuzzer

Update libfuzzer to 4a4cafa

Published: https://crates.io/crates/libfuzzer-sys/0.3.3

fitzgen

comment created time in 13 days

created tagrust-fuzz/libfuzzer

tag0.3.2

Rust bindings and utilities for LLVM’s libFuzzer

created time in 13 days

push eventfitzgen/libfuzzer

Corey Farwell

commit sha df2eb23d4f7ce3b0aaf2fb160b7fb044e800037a

libfuzzer-sys is now 0.3

view details

Nick Fitzgerald

commit sha 9108379f71e4a2e7d11be6f3c64fc3bebd2022c5

Update script for updating libfuzzer vendoring The old compiler-rt repo is deprecated.

view details

Nick Fitzgerald

commit sha 0493bb89c2e97d1dac8a3b52dd2c951d50310b5a

Update libfuzzer to 4a4cafa

view details

Nick Fitzgerald

commit sha 2267e759e9e58d7358c59a2ba292d58f9da7ffed

Bump to version 0.3.3

view details

Nick Fitzgerald

commit sha debb696219e8883deccf3630ab176cc75e1c5fcd

Merge pull request #63 from fitzgen/update-libfuzzer-to-4a4cafa Update libfuzzer to 4a4cafa

view details

push time in 13 days

created tagrust-fuzz/libfuzzer

tag0.3.3

Rust bindings and utilities for LLVM’s libFuzzer

created time in 13 days

delete branch fitzgen/libfuzzer

delete branch : update-libfuzzer-to-4a4cafa

delete time in 13 days

push eventrust-fuzz/libfuzzer

Nick Fitzgerald

commit sha 9108379f71e4a2e7d11be6f3c64fc3bebd2022c5

Update script for updating libfuzzer vendoring The old compiler-rt repo is deprecated.

view details

Nick Fitzgerald

commit sha 0493bb89c2e97d1dac8a3b52dd2c951d50310b5a

Update libfuzzer to 4a4cafa

view details

Nick Fitzgerald

commit sha 2267e759e9e58d7358c59a2ba292d58f9da7ffed

Bump to version 0.3.3

view details

Nick Fitzgerald

commit sha debb696219e8883deccf3630ab176cc75e1c5fcd

Merge pull request #63 from fitzgen/update-libfuzzer-to-4a4cafa Update libfuzzer to 4a4cafa

view details

push time in 13 days

PR merged rust-fuzz/libfuzzer

Reviewers
Update libfuzzer to 4a4cafa

Upgraded libfuzzer to commit 4a4cafa.

Notably, this pulls in the new Entropic engine for libFuzzer, which should boost fuzzing efficiency when enabled. You can enable Entropic by passing -entropic=1 to your built fuzz targets (although, note that it is still labeled "experimental").

+1291 -670

1 comment

46 changed files

fitzgen

pr closed time in 13 days

pull request commentrust-fuzz/libfuzzer

Update libfuzzer to 4a4cafa

Thanks :)

Yeah I personally at least don't expect that we review upstream's changes, since they have their own review process, just rubber stamp them and review the other changes that aren't part of the vendoring.

fitzgen

comment created time in 13 days

PR opened rust-fuzz/libfuzzer

Reviewers
Update libfuzzer to 4a4cafa

Upgraded libfuzzer to commit 4a4cafa.

Notably, this pulls in the new Entropic engine for libFuzzer, which should boost fuzzing efficiency when enabled. You can enable Entropic by passing -entropic=1 to your built fuzz targets (although, note that it is still labeled "experimental").

+1291 -670

0 comment

46 changed files

pr created time in 13 days

push eventfitzgen/libfuzzer

Nick Fitzgerald

commit sha 2267e759e9e58d7358c59a2ba292d58f9da7ffed

Bump to version 0.3.3

view details

push time in 13 days

create barnchfitzgen/libfuzzer

branch : update-libfuzzer-to-4a4cafa

created branch time in 13 days

pull request commentgimli-rs/cpp_demangle

fix: Demangle deeply nested generics by increasing recursion limit

I think that either:

a) This needs to be user-configurable OR b) The max recursion value needs to be bumped to the maximum supported by libiberty (i.e. binutils's demangler) which is 1024 (provided that this does not generally exhaust the stack space on a normal thread).

I think both would be desirable.

Swatinem

comment created time in 13 days

issue commentgoogle/souper

EBNF-style grammar for Souper's text format?

FWIW, my library lives at https://github.com/fitzgen/souper-ir and can now deterministically round-trip every .opt file in souper/test/** and has stood up to some basic fuzzing (just checking for no panics and that if we can parse, then we can stringify, re-parse that, and re-stringify to the same string again; doesn't do differential fuzzing against Souper's hand written parser like we talked about above).

I also updated the grammar in the OP based on some changes I found while implementing my library.

fitzgen

comment created time in 16 days

issue commentgoogle/souper

EBNF-style grammar for Souper's text format?

Also, my parser is hand-written as well. Not mechanically generated from the grammar..

fitzgen

comment created time in 16 days

delete branch fitzgen/souper-ir

delete branch : stringify

delete time in 16 days

push eventfitzgen/souper-ir

Nick Fitzgerald

commit sha 78e51eb8b6dc5e6f513be7b6a89eb1357fecd869

Update souper for bug fix

view details

Nick Fitzgerald

commit sha 85b928f30b580bae42b18238be63aa6caa4acc30

Implement stringifying ASTs into souper source text Also check that we can deterministically round trip souper test files and also fuzzer inputs that we successfully parse.

view details

Nick Fitzgerald

commit sha 54f4888c38446cb01977a905158ef4377e880b94

Implement builders and add examples to docs

view details

Nick Fitzgerald

commit sha 37a7c6c2bc9db3655a822e3ec48ce86cee1205d5

Bump to version 1.0.0

view details

Nick Fitzgerald

commit sha 27acceabdf813fb9e6adf596c34944307e36454e

Update README

view details

Nick Fitzgerald

commit sha 245859b8e8827945e8ec8e986219d6af30d4813e

Merge pull request #3 from fitzgen/stringify Stringify ASTs back to souper source text; bump to 1.0

view details

push time in 16 days

push eventfitzgen/souper-ir

Nick Fitzgerald

commit sha 27acceabdf813fb9e6adf596c34944307e36454e

Update README

view details

push time in 16 days

PR opened fitzgen/souper-ir

Stringify ASTs back to souper source text; bump to 1.0
+953 -39

0 comment

10 changed files

pr created time in 16 days

create barnchfitzgen/souper-ir

branch : stringify

created branch time in 16 days

push eventfitzgen/souper-ir

Nick Fitzgerald

commit sha ca203b80821c518899496888a0920f7459f48da0

Fix cargo workspace

view details

push time in 16 days

delete branch fitzgen/souper-ir

delete branch : more-parsing

delete time in 16 days

push eventfitzgen/souper-ir

Nick Fitzgerald

commit sha c69272f2987b567304d080905541f02c497e3df7

Add a simple fuzzer for parsing

view details

Nick Fitzgerald

commit sha 4001cf9ad72fef38c6fddb6bfbe33e6dbadc09d0

Build fuzz targets in CI

view details

Nick Fitzgerald

commit sha be82e4e1ad1fe816274a90f94dcadad3b5e47e33

Fix a few parser bugs found by the fuzzer

view details

Nick Fitzgerald

commit sha 6eb1bee36a84fe87c43dd369ca287f35cb1b2bb1

Fill out some documentation for the parser

view details

Nick Fitzgerald

commit sha 3e5e5f57e16a60a2251d002cb0da42812dee1fe6

Ensure we can parse every `.opt` file in Souper's tests

view details

Nick Fitzgerald

commit sha 50a7d6563e1b250fd27a3bb4062e49b9052b29e1

Merge pull request #2 from fitzgen/more-parsing More parsing stuff

view details

push time in 16 days

PR merged fitzgen/souper-ir

More parsing stuff
+247 -93

0 comment

12 changed files

fitzgen

pr closed time in 16 days

delete branch fitzgen/souper

delete branch : fix-comment-in-test

delete time in 16 days

push eventfitzgen/souper-ir

Nick Fitzgerald

commit sha 3e5e5f57e16a60a2251d002cb0da42812dee1fe6

Ensure we can parse every `.opt` file in Souper's tests

view details

push time in 16 days

PR opened fitzgen/souper-ir

More parsing stuff
+246 -93

0 comment

12 changed files

pr created time in 16 days

create barnchfitzgen/souper-ir

branch : more-parsing

created branch time in 16 days

PR opened google/souper

Fix comment in test

Found this while making sure that my parser could handle every .opt file under souper/test/**.

@regehr, please take a look, thanks!

+2 -3

0 comment

1 changed file

pr created time in 16 days

create barnchfitzgen/souper

branch : fix-comment-in-test

created branch time in 16 days

fork fitzgen/souper

A superoptimizer for LLVM IR

fork in 16 days

delete branch fitzgen/souper-ir

delete branch : ast-and-parser

delete time in 16 days

push eventfitzgen/souper-ir

Nick Fitzgerald

commit sha 263098f5632d71e34e9383045539432c89f165c7

Define AST types

view details

Nick Fitzgerald

commit sha e23f57356b46a98b8f130aecffb8389b1f7c3c0b

Implement a parser for the Souper text format

view details

Nick Fitzgerald

commit sha 84997d021515787210a283514eb21a1be84bdc35

Merge pull request #1 from fitzgen/ast-and-parser Define AST and implement parser

view details

push time in 16 days

PR merged fitzgen/souper-ir

Define AST and implement parser
+1479 -18

0 comment

3 changed files

fitzgen

pr closed time in 16 days

PR opened fitzgen/souper-ir

Define AST and implement parser
+1479 -18

0 comment

3 changed files

pr created time in 16 days

create barnchfitzgen/souper-ir

branch : ast-and-parser

created branch time in 16 days

Pull request review commentrustwasm/wasm-bindgen

Update support for weak referenes

 where         }     } -    /// Leaks this `Closure` to ensure it remains valid for the duration of the-    /// entire program.+    /// Release memory management of this closure from Rust to the JS GC.     ///-    /// > **Note**: this function will leak memory. It should be used sparingly-    /// > to ensure the memory leak doesn't affect the program too much.+    /// When a `Closure` is dropped it will release the Rust memory and+    /// invalidate the associated JS closure, but this isn't always desired.+    /// Some callbacks are alive for the entire duration of the program or for a+    /// lifetime dynamically managed by the JS GC. This function can be used+    /// to drop this `Closure` while keeping the associated JS function still+    /// valid.     ///-    /// When a `Closure` is dropped it will invalidate the associated JS-    /// closure, but this isn't always desired. Some callbacks are alive for-    /// the entire duration of the program, so this can be used to conveniently-    /// leak this instance of `Closure` while performing as much internal-    /// cleanup as it can.-    pub fn forget(self) {-        unsafe {-            super::__wbindgen_cb_forget(self.js.idx);-            mem::forget(self);-        }+    /// By default this function will leak memory. This can be dangerous if this+    /// function is called many times in an application because the memory leak+    /// will overwhelm the page quickly and crash the wasm.+    ///+    /// If the browser, however, supports weak references, then this function+    /// will not leak memory. Instead the Rust memory will be reclaimed when the+    /// JS closure is GC'd. Weak references are not enabled by default since+    /// they're still a proposal for the JS standard. They can be enabled with+    /// `WASM_BINDGEN_WEAKREF=1` when running `wasm-bindgen`, however.

I don't think we are at default-on yet. Probably not for a year or so, I'd guess, if ever :-/

alexcrichton

comment created time in 17 days

Pull request review commentrustwasm/wasm-bindgen

Update support for weak referenes

 where         }     } -    /// Leaks this `Closure` to ensure it remains valid for the duration of the-    /// entire program.+    /// Release memory management of this closure from Rust to the JS GC.     ///-    /// > **Note**: this function will leak memory. It should be used sparingly-    /// > to ensure the memory leak doesn't affect the program too much.+    /// When a `Closure` is dropped it will release the Rust memory and+    /// invalidate the associated JS closure, but this isn't always desired.+    /// Some callbacks are alive for the entire duration of the program or for a+    /// lifetime dynamically managed by the JS GC. This function can be used+    /// to drop this `Closure` while keeping the associated JS function still+    /// valid.     ///-    /// When a `Closure` is dropped it will invalidate the associated JS-    /// closure, but this isn't always desired. Some callbacks are alive for-    /// the entire duration of the program, so this can be used to conveniently-    /// leak this instance of `Closure` while performing as much internal-    /// cleanup as it can.-    pub fn forget(self) {-        unsafe {-            super::__wbindgen_cb_forget(self.js.idx);-            mem::forget(self);-        }+    /// By default this function will leak memory. This can be dangerous if this+    /// function is called many times in an application because the memory leak+    /// will overwhelm the page quickly and crash the wasm.+    ///+    /// If the browser, however, supports weak references, then this function+    /// will not leak memory. Instead the Rust memory will be reclaimed when the+    /// JS closure is GC'd. Weak references are not enabled by default since+    /// they're still a proposal for the JS standard. They can be enabled with+    /// `WASM_BINDGEN_WEAKREF=1` when running `wasm-bindgen`, however.

Maybe time to make an actual CLI flag, now that these are pretty far down the standards pipeline.

alexcrichton

comment created time in 17 days

more