[LLHD] Add coroutine, call_coroutine, return ops#10068
Conversation
|
Results of circt-tests run for 85a7160 compared to results for 1252379: sv-testsChanges in emitted diagnostics:
|
| /// Verify the type attribute of this coroutine. | ||
| mlir::LogicalResult verifyType() { | ||
| auto type = getFunctionTypeAttr().getValue(); | ||
| if (!llvm::isa<mlir::FunctionType>(type)) | ||
| return emitOpError("requires '") << getFunctionTypeAttrName() << | ||
| "' attribute of function type"; | ||
| return mlir::success(); | ||
| } |
There was a problem hiding this comment.
Isn't this already verified by ODS?
There was a problem hiding this comment.
Huh good point, that should already be covered by ODS!
uenoku
left a comment
uenoku
left a comment
There was a problem hiding this comment.
It looks straightforward definition for function like operations, LGTM.
One datapoint is CIR is representing coroutine an attribute on cir.func op(https://github.com/llvm/llvm-project/blob/a2d84b5d8d9c3ae3a07c4f47cd1b6b8f64be1b41/clang/include/clang/CIR/Dialect/IR/CIROps.td#L3610-L3611). Though I think creating an new operation seems more reasonable here.
|
An attribute would definitely also be a valid option! For that we'd have to create a custom |
When a task reads a module-scope signal in an event control expression like `@(posedge clk)`, the signal must be captured as an extra argument to the task function. Previously, `convertTimingControl` set the `rvalueReadCallback` to null to prevent event control reads from polluting implicit `@*` sensitivity lists. This also suppressed the function capture callback, causing the signal to be used across region boundaries without being plumbed as an argument. Replace the callback nulling with an `isInsideTimingControl` flag. The implicit event callback checks this flag before recording reads, while function capture callbacks (which don't check it) continue to work. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add `llhd.coroutine`, `llhd.call_coroutine`, and `llhd.return` ops to represent suspendable subroutines (SystemVerilog tasks) in the LLHD dialect. Coroutines are `IsolatedFromAbove` function-like ops that can contain `llhd.wait` and `llhd.halt`, just like processes. Calling a coroutine suspends the caller until the coroutine returns. Update the parent constraints on `llhd.wait` and `llhd.halt` to also allow `llhd.coroutine` as a parent. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
fabianschuiki
force-pushed
the
fschuiki/fix-signal-capture
branch
from
1252379 to
2cfee4e
Compare
fabianschuiki
force-pushed
the
fschuiki/llhd-coroutines
branch
from
85a7160 to
d676ea7
Compare
|
Yeah I think if it had llhd.func it might make sense, but it still feels a bit brittle that you can only use llhd.wait in llhd.func when that specific attribute exists. |
|
Results of circt-tests run for d676ea7 compared to results for 2cfee4e: sv-testsChanges in emitted diagnostics:
|
2 participants
Add
llhd.coroutine,llhd.call_coroutine, andllhd.returnops to represent suspendable subroutines (SystemVerilog tasks) in the LLHD dialect. Coroutines areIsolatedFromAbovefunction-like ops that can containllhd.waitandllhd.halt, just like processes. Calling a coroutine suspends the caller until the coroutine returns.Update the parent constraints on
llhd.waitandllhd.haltto also allowllhd.coroutineas a parent.