Stream: git-wasmtime

Topic: wasmtime / PR #8293 cranelift: Minimize ways to manipulat...


view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 00:44):

jameysharp requested cfallin for a review on PR #8293.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 00:44):

jameysharp requested wasmtime-compiler-reviewers for a review on PR #8293.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 00:44):

jameysharp opened PR #8293 from jameysharp:cleanup-results to bytecodealliance:main:

In particular, remove support for detaching/attaching/appending instruction results.

The AliasAnalysis pass used detach_results, but leaked the detached ValueList; using clear_results instead is better.

The verifier's test_printing_contextual_errors needed to get the verifier to produce an error containing a pretty-printed instruction, and did so by appending too many results. Instead, failing to append any results gets a similar error out of the verifier, without requiring that we expose the easy-to-misuse append_result method. However, iconst is not a suitable instruction for this version of the test because its result type is its controlling type, so failing to create any results caused assertion failures rather than the desired verifier error. I switched to f64const which has a non-polymorphic type.

The DFG's aliases test cleared both results of an instruction and then reattached one of them. Since we have access to DFG internals in these tests, it's easier to directly manipulate the relevant ValueList than to use these unsafe methods.

The only other use of attach/append was in make_inst_results_reusing which decided which to use based on whether a particular result was supposed to reuse an existing value. Inlining both methods there revealed that they were nearly identical and could have most of their code factored out.

While I was looking at uses of DataFlowGraph::results, I also simplified replace_with_aliases a little bit.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 15:18):

cfallin submitted PR review:

Thanks for this cleanup! A few things below but in general I'm always happy when we can shrink an API :-)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 15:18):

cfallin created PR review comment:

The bound (dest, original) names are slightly confusing given we're iterating over zip(dest_results, src_results) -- can we pick either original or src and use it in both places?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 15:18):

cfallin submitted PR review:

Thanks for this cleanup! A few things below but in general I'm always happy when we can shrink an API :-)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 15:18):

cfallin created PR review comment:

(I realize this is inlined code, but thoughts still follow:)

The as u16 cast here is indeed protected by the assert above, but it's still something that catches my eye and takes a bit to understand safety thereof -- could we instead do the try_from here (overhead is the same in the common case of one result)?

Also, it occurs to me that we want this check even in release builds (if other limits somehow let through a many-result function, we don't want to rely on fuzzing catching a wraparound-caused miscompile before users do); so either a try_from().expect() or a full assert! is probably what we want.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 17:29):

jameysharp updated PR #8293.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 17:30):

jameysharp commented on PR #8293:

Good suggestions, thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 17:30):

jameysharp has enabled auto merge for PR #8293.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 03 2024 at 18:15):

jameysharp merged PR #8293.


Last updated: Dec 23 2024 at 12:05 UTC