-
Notifications
You must be signed in to change notification settings - Fork 281
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
[SV] Add sv.func, sv.return and sv.func.call operations #7003
Conversation
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 cool 🥳
FunctionOpInterface, HasParent<"mlir::ModuleOp">]> { | ||
let summary = "A System Verilog function"; | ||
let description = [{ | ||
`sv.func` reresents System Verilog function in SV spec 13.4. |
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.
`sv.func` reresents System Verilog function in SV spec 13.4. | |
`sv.func` reresents SystemVerilog function in SV spec 13.4. |
Can you also mention which exact version of the spec this is? They tend to insert paragraphs, which makes the numbering unstable. Something like see IEEE 1800-2017 section 13.4 "section title"
maybe?
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.
Added! Thank you for great suggestion!
// Non-procedural call cannot have output arguments. | ||
if (referencedOp.getNumOutputs() != 1 || | ||
!referencedOp.getExplicitlyReturnedType()) { | ||
auto diag = emitError() | ||
<< "function called in a non-procedural region must " | ||
"return a single result"; | ||
diag.attachNote(referencedOp.getLoc()) << "doesn't satisfy the constraint"; | ||
return failure(); | ||
} |
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.
Nice!
I'm going to merge the PR. Post-merge review is welcomed. The current implementation around a return value is slightly hacky especially the use of "sv.func.explicitly_returned". Probably a better way would be to introduce HWFunctionType with an explicit return type but I'll consider it as a follow-up. |
This PR (separated from #6977) adds function call constructs (sv.func, sv.return and sv.func.call) to SV dialect.
sv.func
-- this op is between hw.module and func.func. This op implement interfacesPortList
,HWModuleLike
andFunctionOpInterface
. Similar to hw.module, we can preserve argument names and mix the order of input and output arguments. Following func.func empty body indicates that the op is a declaration. Currently sv/func is defined as "automatic" function in SV.sv.return
-- terminator for sv.func. We cannot reuse neither hw.output nor func.func since they have constraints on parent op(and I think it's not reasonable to loose them).sv.func.call
andsv.func.call.procedural
. Two operations are added because output arguments cannot be used non-procedural regions.