-
Notifications
You must be signed in to change notification settings - Fork 299
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
[FIRRTL] Add a pass to specialize instance choices #6507
Conversation
120bd0b
to
e869858
Compare
if (selectedOption.empty() || selectedCase.empty()) { | ||
markAllAnalysesPreserved(); | ||
return; | ||
} | ||
|
||
auto optionGroup = circuit.lookupSymbol<OptionOp>(selectedOption); | ||
if (!optionGroup) { | ||
markAllAnalysesPreserved(); | ||
return; | ||
} | ||
|
||
auto optionCase = optionGroup.lookupSymbol<OptionCaseOp>(selectedCase); | ||
if (!optionCase) { | ||
markAllAnalysesPreserved(); | ||
return; | ||
} |
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.
I don't think this is a great API---if these fail, then there's a user error and things arguably shouldn't proceed. Specifically, for something like the user specifies an option/case that doesn't exist or misspells it. If the pass silently does a no-op, then it's difficult to debug as it looks like the pass did the wrong thing.
tl;dr: more signalPassFailure()
and tests of this behavior. 😉
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.
We might set up a flow for all designs and ask for specialization for a target, but a smaller input might have no use of options at all, in which case the pass would fail. I think it is reasonable to turn this into a no-op if there is no option to specialize.
To better reflect this, I added warning emission if an option is not found.
@@ -850,4 +850,24 @@ def Lint : | |||
let constructor = "circt::firrtl::createLintingPass()"; | |||
} | |||
|
|||
def SpecializeOption : | |||
Pass<"firrtl-specialize-option", "firrtl::CircuitOp"> { |
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.
This could be a FModuleOp
pass by my reading of https://mlir.llvm.org/docs/PassManagement/#operation-pass. What does the proposed error handling look like in that case?
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.
We'd get a bazillion copies of the error message? I think it's clearer handle parallelism within the pass in this case.
ebef73b
to
f23cd10
Compare
7ad0c0d
to
035c097
Compare
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 good.
Please add tests of all error/warning paths that this pass can take.
The `SpecializeOptions` pass eliminates instance choices and replaces them with instances targeting the modules associated with a case provided through the options.
035c097
to
4b6ec9f
Compare
The
SpecializeOptions
pass eliminates instance choices and replaces them with instances targeting the modules associated with a case provided through the options.