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

Better Pass Infrastructure #1832

Open
acl-cqc opened this issue Jan 3, 2025 · 0 comments
Open

Better Pass Infrastructure #1832

acl-cqc opened this issue Jan 3, 2025 · 0 comments

Comments

@acl-cqc
Copy link
Contributor

acl-cqc commented Jan 3, 2025

At present we have a bunch of things that call themselves Passes - ConstantFoldPass, MonomorphizePass, RemoveDeadFuncsPass.

Each of these has its own copy of code to allow setting a ValidationLevel, and some have other pass-specific configuration. There is no common interface - the idea of a "pass" is purely conceptual. They then run via ValidationLevel::run_validated_pass with a callback (leading to quite a complicated signature, and possibly fun with the borrow-checker).

We could improve on this via:

  • A trait Pass which could be roughly, fn run(h: &mut impl HugrMut) -> Result<(), Self::Error> (plus associated type Error)
  • A ValidatingPass<P: Pass>(P, ValidationLevel) that wraps another pass with something like the current ValidationLevel but without ValidationLevel::None. We could have a single ValidationPassError<E> that reports either an error in validation (before/after) or an underlying error E
  • Some kind of "SequencePass" that wraps a bunch of other passes (I think this would have to use dyn so maybe just two arbitrary passes) - and we can add methods to trait Pass that combine Passes e.g. and_then(other: impl Pass) -> impl Pass. This would combine with the previous to allow validation before/after a number of passes but not at steps inbetween.
  • Maybe common config for specifying inputs, reachable functions, anything else - e.g. constant folding: FuncDefns and FuncDecls are not considered needed #1797 / Decide on which functions are "public" #1752
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant