Enforce ordering on custom pass annotations #446
Comments
|
One thing I might add, and not sure if anyone's really tried -- for ResetInverter, i assume the invert(this) thing could also be run from some higher module that instantiates a Module with ResetInverter (or whatever it was called) trait. If that's the case, people might be able to order them to some degree... but when dealing with transforms done on the top level module, I'm not sure how one goes about doing that with Chisel Driver? I'm still kind of confused about how the (): => stuff works... I guess it gets weird when you start mixing/matching module level transforms vs. circuit level transforms, etc. So there still needs to be some way to feed in critical ordering, should it be necessary. |
|
As another example: I need my AddPads Transform to come before BlackBoxHelper, but I don't know if there's any way to guarantee that, given that both transforms should occur on LowForm. |
|
Current thoughts: list of passes required before/after running - topo sort, then insert lowering passes to fix form mismatches |
This adds a Dependency API (#948) to the firrtl.options package. This adds two new methods to Phase: prerequisites and invalidates. The former defines what Phases must have run before this Phase. The latter is a function that can be used to determine if this Phase invalidates another Phase. Additionally, this introduces a PhaseManager that subclasses Phase that determines a sequence of Phases to perform a requested lowering (from a given initial state ensure that some set of Phases are executed). This follows the original suggestion of @azidar in #446 for the PhaseManager algorithm with one modification. The (DFS-based) topological sort of dependencies is seeded using a topological sort of the invalidations. This ensures that the number of repeated Phases is kept to a minimum. (I am not sure if this is actually optimal, however.) DiGraph is updated with a seeded topological sort which the original topological sort method (linearize) now extends. Signed-off-by: Schuyler Eldridge <schuyler.eldridge@ibm.com>
This adds the PhaseManager class which can be used to determine a sequence of Phases that should be run given the new Dependency API. A PhaseManager determines an ordering that results in some target Phases being run (without invalidations) given an initial state (some other set of Phases). This follows the original suggestion of @azidar in #446 with one (critical) modification to the algorithm: the (DFS-based) topological sort of dependencies is seeded using a topological sort of the invalidations (this uses the DiGraph.seededLinearize method). This ensures that the number of repeated Phases is kept to a minimum. (I am not sure if this is actually optimal, however.) Signed-off-by: Schuyler Eldridge <schuyler.eldridge@ibm.com>
|
Current approach in #1123 is that you get two ways of defining dependencies:
Implementation-wise for (2) explicit dependencies are not added based on the order. |
When directly calling a firrtl compiler with custom transforms the user has the ability to enforce an order between their passes. If annotations are used to add custom transforms there is no extant way to order them. This would be a very useful feature.
The text was updated successfully, but these errors were encountered: