-
Notifications
You must be signed in to change notification settings - Fork 13
feat!: Add Hugr entrypoints #2147
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 #2147 +/- ##
==========================================
- Coverage 82.17% 82.10% -0.08%
==========================================
Files 228 227 -1
Lines 39976 39795 -181
Branches 36075 35894 -181
==========================================
- Hits 32852 32672 -180
- Misses 5293 5301 +8
+ Partials 1831 1822 -9
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:
|
CodSpeed Performance ReportMerging #2147 will degrade performances by 23.38%Comparing Summary
Benchmarks breakdown
|
|
This PR contains breaking changes to the public Rust API. cargo-semver-checks summary |
56c110c to
9cd24ff
Compare
fix some root/entrypoint mixups snap! petgraph wrapper fix more things insert_hugr
04a19d3 to
851e396
Compare
ss2165
left a comment
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.
Very happy to see so much red, and more readable code all-round.
the new InsertCut patch that just merged to main will need fixing on the rebase
Co-authored-by: Seyon Sivarajah <[email protected]>
Co-authored-by: Seyon Sivarajah <[email protected]>
Co-authored-by: Seyon Sivarajah <[email protected]>
Co-authored-by: Seyon Sivarajah <[email protected]>
ss2165
left a comment
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.
🚀
Adds entrypoint definitions to `hugr-py`. Has similar caveats to #2147. The main issue here was builders that initialized a hugr for a dataflow op without knowing its output types. The automatic machinery that wraps the op in a function definition needs to connect the outputs to the new function's output once we know the types, so I had to add some extra machinery to `DataflowOp` to signal back to the hugr that it should connect things. This feels a bit hacky, perhaps there's a cleaner way to do it... Blocked by #2147. BREAKING CHANGE: Hugrs now define an `entrypoint` in addition to a module root.
…#2336) This should have been part of #2256 but some confusion dates from #2147. Making a callgraph for only the functions beneath the entrypoint makes no sense - that's either all the functions (if the entrypoint is the root) or at most one of them (if the entrypoint is one of the funcdefns). Of course, we didn't test with any Hugrs that had a non-module-root entrypoint.... so the sensible thing to do now, seems to be for callgraph to ignore the entrypoint. (We can optimize it looking for FuncDefns tho, they are now easy to find.) Dead function removal allowed specifying starting points for analysis (top-level FuncDefns) but only if the Hugr's entrypoint was the module. There seems no good reason not to allow specifying module-level FuncDefns even if the entrypoint is lower, and similarly, we should use the entrypoint as one starting point (perhaps among many) for analysis... (One could rename `entry_points` used by analysis to "starting_points" but that would be breaking)
…#2336) This should have been part of #2256 but some confusion dates from #2147. Making a callgraph for only the functions beneath the entrypoint makes no sense - that's either all the functions (if the entrypoint is the root) or at most one of them (if the entrypoint is one of the funcdefns). Of course, we didn't test with any Hugrs that had a non-module-root entrypoint.... so the sensible thing to do now, seems to be for callgraph to ignore the entrypoint. (We can optimize it looking for FuncDefns tho, they are now easy to find.) Dead function removal allowed specifying starting points for analysis (top-level FuncDefns) but only if the Hugr's entrypoint was the module. There seems no good reason not to allow specifying module-level FuncDefns even if the entrypoint is lower, and similarly, we should use the entrypoint as one starting point (perhaps among many) for analysis... (One could rename `entry_points` used by analysis to "starting_points" but that would be breaking)
Adds the concept of "entrypoint" to the HUGRs, detaching the "main node of interest" from the hierarchy root.
Now hugrs will always have a
Moduleat their root (appropriately calledHugrView::module_root), and any manipulation is mostly focused around the entrypoint instead.Closes #2029
Closes #2010
before:
after:
How does this affect...
...HugrView?
::roothas been split intomodule_rootandentrypoint. In general, you'll want to use the latter (as described in the docs).nodes()is still defined, but now there's alsodescendants(node)andentry_descendants(), which should be preferred....builders?
The change should be transparent for hugr building operations. When you start an specific builder or call
Hugr::new(op)we add additional nodes as necessary so that the new entrypoint is correctly defined inside a module;opis a module, we just leave it at the top.opcan be defined in a module, we put it below the root.opis a dataflow operation, we define a "main" function with the same signature and put it there....SiblingGraph, SiblingMut, and DescendantsGraph?
The structs are no more. Instead,
HugrViewhas two new methods:with_entrypoint(&self, Node) -> Rerooted<&Self>with_entrypoint_mut(&mut self, Node) -> Rerooted<&mut Self>The new wrapper implements
HugrMut, so it can be used transparently.The main benefit of this is that
Rerootedstill contains all the nodes that are not descendants from the entrypoint. So external edges are still well-defined, and rewrite operations may still put look at the root module and define things there if needed....serialization?
The hugr json now has an
entrypointfield. If missing, we assume it's the root.For backwards compatibility, if the serialized root is not a module we will transparently wrap it as described before so older jsons will continue working without modifications.
hugr-module encoding is left as a TODO
...packages and envelopes?
Now every HUGR can be put in a package without modifications!
Ideally we'll now be able to remove the hugr <-> json methods and only use envelopes. (That's a TODO).
...mermaid/dot renders?
The entrypoint node is now highlighted in purple, and its title shown in bold between brackets. See the example above.
...passes?
Things should work as normal. New passes should look at the entrypoint and its descendants when looking for things to rewrite, instead of the whole hugr.
TODOs not in this PR:
hugr-py#2148hugr-modulesupport Module entrypoints inhugr-model#2156impl {De,}Serialize for Hugr#2159BREAKING CHANGE:
Hugrs now have an entrypoint node.BREAKING CHANGE: Removed
SiblingGraph/SiblingMut/DescendantsGraph