================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
