================
@@ -465,12 +465,48 @@ static cir::CIRCallOpInterface
emitCallLikeOp(CIRGenFunction &cgf, mlir::Location callLoc,
cir::FuncType indirectFuncTy, mlir::Value indirectFuncVal,
cir::FuncOp directFuncOp,
- const SmallVectorImpl<mlir::Value> &cirCallArgs,
+ const SmallVectorImpl<mlir::Value> &cirCallArgs, bool isInvoke,
const mlir::NamedAttrList &attrs) {
CIRGenBuilderTy &builder = cgf.getBuilder();
assert(!cir::MissingFeatures::opCallSurroundingTry());
- assert(!cir::MissingFeatures::invokeOp());
+
+ if (isInvoke) {
+ // This call can throw, few options:
+ // - If this call does not have an associated cir.try, use the
+ // one provided by InvokeDest,
+ // - User written try/catch clauses require calls to handle
+ // exceptions under cir.try.
+
+ // In OG, we build the landing pad for this scope. In CIR, we emit a
+ // synthetic cir.try because this didn't come from code generating from a
+ // try/catch in C++.
+ assert(cgf.curLexScope && "expected scope");
+ cir::TryOp tryOp = cgf.curLexScope->getClosestTryParent();
+ if (!tryOp) {
+ cgf.cgm.errorNYI(
+ "emitCallLikeOp: call does not have an associated cir.try");
+ return {};
+ }
+
+ if (tryOp.getSynthetic()) {
+ cgf.cgm.errorNYI("emitCallLikeOp: tryOp synthetic");
+ return {};
+ }
+
+ cir::CallOp callOpWithExceptions;
+ if (indirectFuncTy) {
+ cgf.cgm.errorNYI("emitCallLikeOp: indirect function type");
+ return {};
+ }
+
+ callOpWithExceptions =
+ builder.createTryCallOp(callLoc, directFuncOp, cirCallArgs);
+
+ (void)cgf.getInvokeDest(tryOp);
----------------
AmrDeveloper wrote:
I think isInvokeDest, getInvokeDest and getInvokeDestImpl are not fully correct
names now. I found that `isInvokeDest` is not in OGCG, but it's in CIR. Extract
the condition part from getInvokeDest and return if catch or cleanup may be
required.
I renamed `isInvokeDest` to `isCatchOrCleanupRequired` and removed performing
the same conditions again in `getInvokeDest`, and also merged `getInvokeDest`
and `getInvokeDestImpl` to be `populateCatchHandlersIfRequired`.
The if required part is because, in case of `Personality.usesFuncletPads()`, we
will not populate them.
What do you think? @bcardosolopes @andykaylor.
Also, in case we can simplify `getEHDispatchBlock`, then we can merge
`populateCatchHandlersIfRequired` and `populateCatchHandlers` 🤔
https://github.com/llvm/llvm-project/pull/165158
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
