Stream: git-wasmtime

Topic: wasmtime / issue #5793 Cranelift: concretize the interpreter


view this post on Zulip Wasmtime GitHub notifications bot (Feb 15 2023 at 19:32):

fitzgen opened issue #5793:

Right now the interpreter is generic over the type of value we are interpreting, essentially allowing for abstract interpretation over symbolic values in theory. But we aren't using that functionality. And we have no plans ever to use it in the future: instead we have the egraphs pass and its support for forwards analyses, which is our framework for analyses moving forward.

So can we simplify the interpreter by working with concrete values instead of a type parameter that is bounded by a trait?

cc @abrown @afonso360

view this post on Zulip Wasmtime GitHub notifications bot (Feb 15 2023 at 19:32):

fitzgen labeled issue #5793:

Right now the interpreter is generic over the type of value we are interpreting, essentially allowing for abstract interpretation over symbolic values in theory. But we aren't using that functionality. And we have no plans ever to use it in the future: instead we have the egraphs pass and its support for forwards analyses, which is our framework for analyses moving forward.

So can we simplify the interpreter by working with concrete values instead of a type parameter that is bounded by a trait?

cc @abrown @afonso360

view this post on Zulip Wasmtime GitHub notifications bot (Feb 15 2023 at 22:22):

abrown commented on issue #5793:

I had a working implementation of sparse conditional constant propagation (SCCP) that used the abstract interpreter. All of this was for another project and I recall sending @cfallin some notes on how I made it work because I was leaving on sabbatical and wasn't going to take it any further. I'm not familiar enough with the egraphs stuff yet to say whether it could do the equivalent of SCCP. If it could, I guess simplifying the interpreter makes sense; but if there's any interest in reviving that SCCP code we would want to continue to allow abstract interpretation.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 17 2023 at 22:45):

cfallin commented on issue #5793:

Yup, I didn't end up finding the time to play more with @abrown's SCCP but it was pretty neat (sorry!). I think at this point, we're pretty close to being able to do the equivalent (branch folding plus constants-through-blockparams) in the egraph framework. (@jameysharp, @elliottt, @fitzgen and I have been talking some about this. Happy to discuss more at a Cranelift meeting if folks are interested!) In the meantime, this sounds like a reasonable simplification, IMHO.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 29 2023 at 17:29):

jameysharp commented on issue #5793:

Yeah, I think we have solid plans for branch folding in #6106, and for replacing single-definition block-params in #6109, and I think that means we can do SCCP in the egraph pass. Since we don't currently run the egraph pass to a fix-point, it isn't full SCCP in the presence of loops, but that's a deliberate design decision, and we've talked about making more aggressive optimization optional.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 11 2023 at 11:49):

afonso360 closed issue #5793:

Right now the interpreter is generic over the type of value we are interpreting, essentially allowing for abstract interpretation over symbolic values in theory. But we aren't using that functionality. And we have no plans ever to use it in the future: instead we have the egraphs pass and its support for forwards analyses, which is our framework for analyses moving forward.

So can we simplify the interpreter by working with concrete values instead of a type parameter that is bounded by a trait?

cc @abrown @afonso360


Last updated: Oct 23 2024 at 20:03 UTC