================
@@ -2119,76 +2119,261 @@ def CIR_BinOpOverflowOp : CIR_Op<"binop.overflow",
[Pure, SameTypeOperands]> {
//===----------------------------------------------------------------------===//
-// BinOp
-//===----------------------------------------------------------------------===//
-
-// FIXME: represent Commutative, Idempotent traits for appropriate binops
-def CIR_BinOpKind : CIR_I32EnumAttr<
- "BinOpKind", "binary operation (arith and logic) kind", [
- I32EnumAttrCase<"Mul", 0, "mul">,
- I32EnumAttrCase<"Div", 1, "div">,
- I32EnumAttrCase<"Rem", 2, "rem">,
- I32EnumAttrCase<"Add", 3, "add">,
- I32EnumAttrCase<"Sub", 4, "sub">,
- I32EnumAttrCase<"And", 5, "and">,
- I32EnumAttrCase<"Xor", 6, "xor">,
- I32EnumAttrCase<"Or", 7, "or">,
- I32EnumAttrCase<"Max", 8, "max">
-]>;
+// Binary Arithmetic and Logic Operations
+//===----------------------------------------------------------------------===//
-def CIR_BinOp : CIR_Op<"binop", [
- Pure, SameTypeOperands, SameOperandsAndResultType
-]> {
- let summary = "Binary operations (arith and logic)";
+// Base class for all CIR binary arithmetic/logic operations.
+// `type` constrains the lhs/rhs/result type.
+class CIR_BinaryOp<string mnemonic, Type type, list<Trait> traits = []>
+ : CIR_Op<mnemonic, !listconcat([
+ NoMemoryEffect, SameOperandsAndResultType,
+ DeclareOpInterfaceMethods<CIR_BinaryOpInterface>
+ ], traits)>
+{
+ let arguments = (ins
+ type:$lhs,
+ type:$rhs
+ );
+
+ let results = (outs type:$result);
+
+ let assemblyFormat = [{
+ $lhs `,` $rhs `:` type($lhs) attr-dict
+ }];
+}
+
+// Base class for binary ops that support integer overflow flags (nsw/nuw)
+// and saturated arithmetic.
+class CIR_BinaryOverflowOp<string mnemonic, Type type, list<Trait> traits = []>
----------------
andykaylor wrote:
We already have `CIR_BinOpOverflowOp`, which does something different than
this. The naming of either in isolation would be appropriate, but together it's
problematic. What would you think of `CIR_BinaryOpWithOverflowFlags` here and
`CIR_BinaryOpWithOverflowChecks` for the other (which I assume we'll also want
to split into separate ops)? Given that this is a base class, the extra
verbosity isn't really a problem.
https://github.com/llvm/llvm-project/pull/184227
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
