-
Notifications
You must be signed in to change notification settings - Fork 8
feat!: Handle CallIndirect in constant folding #2046
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
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2046 +/- ##
==========================================
+ Coverage 83.17% 83.21% +0.04%
==========================================
Files 215 217 +2
Lines 41312 41910 +598
Branches 37526 38124 +598
==========================================
+ Hits 34362 34877 +515
- Misses 5006 5079 +73
- Partials 1944 1954 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This PR contains breaking changes to the public Rust API. cargo-semver-checks summary
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, just missing the tests.
This recursion may be expensive (...). Should be put it under a switch?
You mean to enabling/disabling callindirect folding altogether?
I'd say we can wait and see if it's necessary, but I guess we could add a ConstFoldConfig
struct here since we're breaking the API already.
hugr-passes/src/const_fold.rs
Outdated
@@ -2,18 +2,15 @@ | |||
//! Constant-folding pass. | |||
//! An (example) use of the [dataflow analysis framework](super::dataflow). | |||
|
|||
pub mod value_handle; | |||
mod value_handle; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's quite annoying that we have to make this a breaking change.
It looks like even leaving this as public wouldn't help, since ValueHandle
is not non_exhaustive
and added new fields -.-
Is it OK to wait in merging this PR until we accumulate other breaking changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was hiding that because I thought that's the way that it should have been, would have avoided this being a breaking change now...
How urgent....I was gonna say, the bit we need first is the constant_fold_with_hugr
and that's non-breaking so I can break that out and leave the rest as a demo (just tests that the ValueHandle/CallIndirect works would confirm we can do the same approach in/for BRAT).
However....now I realize we need to get the ValueHandle::NodeRef into the BRAT-specific constant-folding code. At present extension-provided constant-folders only get Hugr Value
s, so rather than adding constant_fold_with_hugr
I think I need some kind of plugin interface to the constant-folding pass that lets us get at those ValueHandles after all. So I think I'll have to restore pub
ness and figure out what the plugin interface is.
Closing in favour of #2059 |
LoadFunction
by stealing the body of the loaded function, will not work for functions with incoming static edges (i.e. from other functions/constants).interpret_call_indirect
method totrait DFContext
(alongsideinterpret_leaf_op
), again defaulting to { }join
ed together). Should be put it under a switch?BREAKING CHANGE: mod value_handle (containing ValueHandle and HashedConst) is no longer
pub
.