================
@@ -55,10 +55,154 @@ mlir::LogicalResult CIRGenFunction::emitStmt(const Stmt *s,
if (mlir::succeeded(emitSimpleStmt(s, useCurrentScope)))
return mlir::success();
- // Only a subset of simple statements are supported at the moment. When more
- // kinds of statements are supported, a
- // switch (s->getStmtClass()) {
- // will be added here.
+ switch (s->getStmtClass()) {
+
+#define STMT(Type, Base)
+#define ABSTRACT_STMT(Op)
+#define EXPR(Type, Base) case Stmt::Type##Class:
+#include "clang/AST/StmtNodes.inc"
+ {
+ // Remember the block we came in on.
+ mlir::Block *incoming = builder.getInsertionBlock();
+ assert(incoming && "expression emission must have an insertion point");
+
+ emitIgnoredExpr(cast<Expr>(s));
----------------
andykaylor wrote:
Yes, this is far from obvious. StmtNodes.inc uses a system of macros and
preprocessors statements, so when it is included what you get for each one is
somewhat determined by which of the macros the client has defined. In this
case, we're getting expressions that are neither statements or abstract
statements (because we define STMT and ABSTRACT_STMT but do nothing with them).
The exact list, of course, depends on what's in StmtNodes.td and how things are
defined there.
FWIW, this matches the handling in the classic codegen
(https://github.com/llvm/llvm-project/blob/1a626e63b5a009075eea87c01f0661144b1ec010/clang/lib/CodeGen/CGStmt.cpp#L130).
https://github.com/llvm/llvm-project/pull/130869
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
