-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block order and value number affects whether we get valid CLIF after optimizations #7857
Comments
With a small patch to get bugpoint to actually work on this test case and a fair amount of manual work I got it reduced to:
which gives the following verifier error:
|
I took a quick look at this (I'm still on leave, only have a brief window here, but figured my input could be useful after seeing this go by). It seems to me at least that there's an issue with the cost function: the select is union'ing with one of its inputs (because it is being constant-folded), but then another user of that input elsewhere is picking the select instead. (Given
Alternately, in a universe where we have use-site-specific costs, we could push the cost of blockparams that are not available (not in a dominating block) to infinity. But we've avoided use-site-specific costs so far because that removes the ability to have the nice linear-time dynamic programming pass to compute them... (Why hasn't this come up before? The |
@elliottt, @fitzgen, and I have been debugging this quite a bit today. Sorry haven't fully caught up on the latest comments. Our findings are:
@fitzgen is going to leave a further comment about the possibility of running Answering some questions reading over your comment now @cfallin
We've concluded this is due to the numbers of values here. Due to the single pass in
My naive understanding at this point is that if all values are defined with values defined before it then we can correctly calculate cost and will deterministically pick |
I think we should do a fixed point here, and I know that is a scary thing to just drop in chat, but I think it is actually fine. The maximum number of iterations the fixed-point loop would take is equal to the longest chain of Additionally, this would allow us to remove the funky infinity-minus-one cost clamping as well, which would be a very nice simplification. I think this might also fix some of the issues discussed in #6126. |
This (two values in the eclass) is "right and good and normal" I think -- if The key I think is the directionality, and for that we need to stick to the "correctness condition" we've stated for rewrite rules -- removing but not adding inputs -- in the extraction (picking nodes for each class) too. If one enode in an eclass depends on So all this leads me to come again to the cost function, and I agree @fitzgen's approach feels like the right one. Basically we need to (i) define costs correctly, so a rewrite rule that "shrinks" the input set also results in a node with lower cost -- this should already be the case, and is a separate bug if not -- and (ii) compute costs correctly according to their definition, which the fixpoint approach should do. |
I have a fix in #7859 |
(please feel free to respond to this after you're back @cfallin, no urgency on this of course)
In the past I've been under the impression that one of the properties of eclasses/elaboration that we rely on is that correctness is guaranteed because no matter what we choose in an eclass it's guaranteed to have the same program. Put another way I was under the impression that various bits and pieces of code relied on the fact that we can choose anything in an eclass to elaborate. What you're saying I agree with, however, and if the above program is correctly putting everything in the same eclass then the I also agree with the consequence, the cost function is quite important. Is there perhaps other bits and pieces of elaboration that need to be updated/rethought? Or is this perhaps a mistaken impression I've gotten from egraphs/etc? (I couldn't actually find docs in Cranelift itself saying anything like this searching for a moment). |
…ass (#7859) * Cranelift: Use a fixpoint loop to compute the best value for each eclass Fixes #7857 * Remove fixpoint loop early-continue optimization * Add document describing optimization rule invariants * Make select optimizations use subsume * Remove invalid debug assert * Remove now-unused methods * Add commutative adds to cost tests
…ass (bytecodealliance#7859) * Cranelift: Use a fixpoint loop to compute the best value for each eclass Fixes bytecodealliance#7857 * Remove fixpoint loop early-continue optimization * Add document describing optimization rule invariants * Make select optimizations use subsume * Remove invalid debug assert * Remove now-unused methods * Add commutative adds to cost tests
…ass (#7859) (#7878) * Cranelift: Use a fixpoint loop to compute the best value for each eclass Fixes #7857 * Remove fixpoint loop early-continue optimization * Add document describing optimization rule invariants * Make select optimizations use subsume * Remove invalid debug assert * Remove now-unused methods * Add commutative adds to cost tests
…ass (bytecodealliance#7859) * Cranelift: Use a fixpoint loop to compute the best value for each eclass Fixes bytecodealliance#7857 * Remove fixpoint loop early-continue optimization * Add document describing optimization rule invariants * Make select optimizations use subsume * Remove invalid debug assert * Remove now-unused methods * Add commutative adds to cost tests
* Guard recursion in `will_simplify_with_ireduce` (#7882) Add a test to expose issues with unbounded recursion through `iadd` during egraph rewrites, and bound the recursion of `will_simplify_with_ireduce`. Fixes #7874 Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com> * Cranelift: Use a fixpoint loop to compute the best value for each eclass (#7859) * Cranelift: Use a fixpoint loop to compute the best value for each eclass Fixes #7857 * Remove fixpoint loop early-continue optimization * Add document describing optimization rule invariants * Make select optimizations use subsume * Remove invalid debug assert * Remove now-unused methods * Add commutative adds to cost tests * Add missing subsume uses in egraph rules (#7879) * Fix a few egraph rules that needed `subsume` There were a few rules that dropped value references from the LHS without using subsume. I think they were probably benign as they produced constant results, but this change is in the spirit of our revised guidelines for egraph rules. * Augment egraph rule guideline 2 to talk about constants * Update release notes --------- Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Last night we got a fuzz bug. Everything below is relative to Wasmtime at 0d662c9.
This input:
will panic in regalloc
This surfaces a validation error in CLIF earlier with validation enabled
This has been further reduced to this CLIF test case:
which can be reproduced with:
I've been investigating this with @elliottt and @fitzgen in person for a bit now. So far we have concluded a few "fixes" can be applied:
v12
input tov1
in CLIF.block3
to be beneathblock0
.(subsume x)
Naturally none of these are actual fixes but are symptoms of the "real" issue. We're still figuring things out at this time but I wanted to open this up.
Trevor and Nick are telling me as well that this is possibly related to #6126.
The text was updated successfully, but these errors were encountered: