[clang] [CIR] Upstream initial support for unary op (PR #131369)
Andy Kaylor via cfe-commits
cfe-commits at lists.llvm.org
Fri Mar 14 11:53:41 PDT 2025
================
@@ -468,6 +468,55 @@ def BrOp : CIR_Op<"br",
}];
}
+//===----------------------------------------------------------------------===//
+// UnaryOp
+//===----------------------------------------------------------------------===//
+
+def UnaryOpKind_Inc : I32EnumAttrCase<"Inc", 1, "inc">;
+def UnaryOpKind_Dec : I32EnumAttrCase<"Dec", 2, "dec">;
+def UnaryOpKind_Plus : I32EnumAttrCase<"Plus", 3, "plus">;
+def UnaryOpKind_Minus : I32EnumAttrCase<"Minus", 4, "minus">;
+def UnaryOpKind_Not : I32EnumAttrCase<"Not", 5, "not">;
+
+def UnaryOpKind : I32EnumAttr<
+ "UnaryOpKind",
+ "unary operation kind",
+ [UnaryOpKind_Inc,
+ UnaryOpKind_Dec,
+ UnaryOpKind_Plus,
+ UnaryOpKind_Minus,
+ UnaryOpKind_Not,
+ ]> {
+ let cppNamespace = "::cir";
+}
+
+// FIXME: Pure won't work when we add overloading.
----------------
andykaylor wrote:
I wasn't sure what the comment meant, but I wasn't comfortable deleting it. I did some checking, and CIR also implements operator overloading as function calls right now (in the incubator), but maybe there is a plan to eventually model them using the base operations. I could see a case for the latter, because a mangled function name isn't particular helpful in reasoning about what something is doing. On the other hand, you obviously can't rely on the overloaded operator even doing something related to what it is overloading, so maybe the opaque call is better.
https://github.com/llvm/llvm-project/pull/131369
More information about the cfe-commits
mailing list