================
@@ -898,6 +898,36 @@ def CIR_ContinueOp : CIR_Op<"continue", [Terminator]> {
let hasLLVMLowering = false;
}
+//===----------------------------------------------------------------------===//
+// Resume
+//===----------------------------------------------------------------------===//
+
+def CIR_SCFResumeOp : CIR_Op<"scf.resume", [
----------------
AmrDeveloper wrote:
In the incubator, we have one ResumeOp that has 2 modes (Similar to
CatchParamOp).
First mode in the unwind block
```
cir.try {
} unwind {
cir.resume <----
}
```
And the second mode after the CFG flattening
```
^bb(%exception: ...., %type_id: .....)
cir.resume %exception, %type_id <-----
```
In FlattenCFG, we replace ResumeOp with another ResumeOp, but we fill the
arguments in the new Op
```
rewriter.replaceOpWithNewOp<cir::ResumeOp>(
resume, unwindBlock->getArgument(0), unwindBlock->getArgument(1));
```
- In the first mode, I don't think naming it `unwind_resume` will add more
context because it's only used in the unwind block.
- We need to define a pattern for Op that was used in 2 modes and is now
converted into 2 ops. Either we can add a prefix for the structured one or the
other one, so if we renamed this one `cir.resume`, that means we will rename
the non-SCF ops with a prefix? 🤔 because we will face the same question in
`CatchParamOp` too.
What do you think?
https://github.com/llvm/llvm-project/pull/170042
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
