Skip to content
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

Rework redundant_join so it is recursion_safe #18172

Closed
Tracked by #17915
aalexandrov opened this issue Mar 16, 2023 · 0 comments · Fixed by #18731
Closed
Tracked by #17915

Rework redundant_join so it is recursion_safe #18172

aalexandrov opened this issue Mar 16, 2023 · 0 comments · Fixed by #18731
Assignees

Comments

@aalexandrov
Copy link
Contributor

aalexandrov commented Mar 16, 2023

Size estimate

L

Notes

The transform maintains a Let-based context in the form of Vec<ProvInfo> for each LocalId in scope.

LetRec implementation (basic)

As a first approximation, we can descend in LetRec values and body by just setting the Vec<ProvInfo> of each LetRec binding to ProvInfo::make_leaf(*id, typ.arity()). In other words, we don't attempt to derive additional provenance information for a binding from its associated value definition.

LetRec implementation (intermediate)

Taken from a PR comment: We can add the result of the action to lets the same way as the Let case does. Gets that reach across iteration boundaries would still be leaves, but Gets that refer to the same iteration would have some provenance that they collected within the iteration. I think this would be equivalent to doing exactly one step of a pessimistic fixpoint loop. (ProvInfo::make_leaf is the top, right?)

(This will only be sound if we can assert that the transfer functions for ProvInfo inference for all possible MirRelationExpr variants are monotonic.)

LetRec implementation (advanced)

We can do something similar to ColumnKnowledge and try to run the ProvInfo analysis (without acting on it) until we reach a fixpoint. We can then descend and apply all transformations. This should be safe as rewriting the join based on the ProvInfo should not invalidate gathered ProvInfo (even for recursive bindings).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant