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
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
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.
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.
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.
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: Dec 23 2024 at 12:05 UTC