[mlir][arith][nfc] Cleanup whitespace in td files (#155109)

Author: Hardcode84

mlir/include/mlir/Dialect/Arith/IR/ArithBase.td

@@ -20,10 +20,10 @@ def Arith_Dialect : Dialect {
     mathematical operations. This includes unary, binary, and ternary arithmetic
     ops, bitwise and shift ops, cast ops, and compare ops. Operations in this
     dialect also accept vectors and tensors of integers or floats. The dialect
-    assumes integers are represented by bitvectors with a two's complement 
-    representation. Unless otherwise stated, the operations within this dialect 
-    propagate poison values, i.e., if any of its inputs are poison, then the 
-    output is poison. Unless otherwise stated, operations applied to `vector` 
+    assumes integers are represented by bitvectors with a two's complement
+    representation. Unless otherwise stated, the operations within this dialect
+    propagate poison values, i.e., if any of its inputs are poison, then the
+    output is poison. Unless otherwise stated, operations applied to `vector`
     and `tensor` values propagates poison elementwise.
   }];
 
@@ -93,9 +93,9 @@ def ATOMIC_RMW_KIND_XORI     : I64EnumAttrCase<"xori", 15>;
 
 def AtomicRMWKindAttr : I64EnumAttr<
     "AtomicRMWKind", "",
-    [ATOMIC_RMW_KIND_ADDF, ATOMIC_RMW_KIND_ADDI, ATOMIC_RMW_KIND_ANDI, 
+    [ATOMIC_RMW_KIND_ADDF, ATOMIC_RMW_KIND_ADDI, ATOMIC_RMW_KIND_ANDI,
      ATOMIC_RMW_KIND_ASSIGN, ATOMIC_RMW_KIND_MAXIMUMF, ATOMIC_RMW_KIND_MAXNUMF,
-     ATOMIC_RMW_KIND_MAXS, ATOMIC_RMW_KIND_MAXU, ATOMIC_RMW_KIND_MINIMUMF, 
+     ATOMIC_RMW_KIND_MAXS, ATOMIC_RMW_KIND_MAXU, ATOMIC_RMW_KIND_MINIMUMF,
      ATOMIC_RMW_KIND_MINNUMF, ATOMIC_RMW_KIND_MINS, ATOMIC_RMW_KIND_MINU,
      ATOMIC_RMW_KIND_MULF, ATOMIC_RMW_KIND_MULI, ATOMIC_RMW_KIND_ORI,
      ATOMIC_RMW_KIND_XORI]> {

mlir/include/mlir/Dialect/Arith/IR/ArithOps.td

@@ -216,14 +216,14 @@ def Arith_ConstantOp : Op<Arith_Dialect, "constant",
 def Arith_AddIOp : Arith_IntBinaryOpWithOverflowFlags<"addi", [Commutative]> {
   let summary = "integer addition operation";
   let description = [{
-    Performs N-bit addition on the operands. The operands are interpreted as 
-    unsigned bitvectors. The result is represented by a bitvector containing the 
-    mathematical value of the addition modulo 2^n, where `n` is the bitwidth. 
-    Because `arith` integers use a two's complement representation, this operation 
+    Performs N-bit addition on the operands. The operands are interpreted as
+    unsigned bitvectors. The result is represented by a bitvector containing the
+    mathematical value of the addition modulo 2^n, where `n` is the bitwidth.
+    Because `arith` integers use a two's complement representation, this operation
     is applicable on both signed and unsigned integer operands.
 
     The `addi` operation takes two operands and returns one result, each of
-    these is required to be the same type. This type may be an integer scalar type, 
+    these is required to be the same type. This type may be an integer scalar type,
     a vector whose element type is integer, or a tensor of integers.
 
     This op supports `nuw`/`nsw` overflow flags which stands for
@@ -489,8 +489,8 @@ def Arith_DivUIOp : Arith_IntBinaryOp<"divui", [ConditionallySpeculatable]> {
     the most significant, i.e. for `i16` given two's complement representation,
     `6 / -2 = 6 / (2^16 - 2) = 0`.
 
-    Division by zero is undefined behavior. When applied to `vector` and 
-    `tensor` values, the behavior is undefined if _any_ elements are divided by 
+    Division by zero is undefined behavior. When applied to `vector` and
+    `tensor` values, the behavior is undefined if _any_ elements are divided by
     zero.
 
     Example:
@@ -525,9 +525,9 @@ def Arith_DivSIOp : Arith_IntBinaryOp<"divsi", [ConditionallySpeculatable]> {
     Signed integer division. Rounds towards zero. Treats the leading bit as
     sign, i.e. `6 / -2 = -3`.
 
-    Divison by zero, or signed division overflow (minimum value divided by -1) 
-    is undefined behavior. When applied to `vector` and `tensor` values, the 
-    behavior is undefined if _any_ of its elements are divided by zero or has a 
+    Divison by zero, or signed division overflow (minimum value divided by -1)
+    is undefined behavior. When applied to `vector` and `tensor` values, the
+    behavior is undefined if _any_ of its elements are divided by zero or has a
     signed division overflow.
 
     Example:
@@ -562,10 +562,10 @@ def Arith_CeilDivUIOp : Arith_IntBinaryOp<"ceildivui",
   let description = [{
     Unsigned integer division. Rounds towards positive infinity. Treats the
     leading bit as the most significant, i.e. for `i16` given two's complement
-    representation, `6 / -2 = 6 / (2^16 - 2) = 1`. 
+    representation, `6 / -2 = 6 / (2^16 - 2) = 1`.
 
-    Division by zero is undefined behavior. When applied to `vector` and 
-    `tensor` values, the behavior is undefined if _any_ elements are divided by 
+    Division by zero is undefined behavior. When applied to `vector` and
+    `tensor` values, the behavior is undefined if _any_ elements are divided by
     zero.
 
     Example:
@@ -594,9 +594,9 @@ def Arith_CeilDivSIOp : Arith_IntBinaryOp<"ceildivsi",
   let description = [{
     Signed integer division. Rounds towards positive infinity, i.e. `7 / -2 = -3`.
 
-    Divison by zero, or signed division overflow (minimum value divided by -1) 
-    is undefined behavior. When applied to `vector` and `tensor` values, the 
-    behavior is undefined if _any_ of its elements are divided by zero or has a 
+    Divison by zero, or signed division overflow (minimum value divided by -1)
+    is undefined behavior. When applied to `vector` and `tensor` values, the
+    behavior is undefined if _any_ of its elements are divided by zero or has a
     signed division overflow.
 
     Example:
@@ -624,9 +624,9 @@ def Arith_FloorDivSIOp : Arith_TotalIntBinaryOp<"floordivsi"> {
   let description = [{
     Signed integer division. Rounds towards negative infinity, i.e. `5 / -2 = -3`.
 
-    Divison by zero, or signed division overflow (minimum value divided by -1) 
-    is undefined behavior. When applied to `vector` and `tensor` values, the 
-    behavior is undefined if _any_ of its elements are divided by zero or has a 
+    Divison by zero, or signed division overflow (minimum value divided by -1)
+    is undefined behavior. When applied to `vector` and `tensor` values, the
+    behavior is undefined if _any_ of its elements are divided by zero or has a
     signed division overflow.
 
     Example:
@@ -650,8 +650,8 @@ def Arith_RemUIOp : Arith_TotalIntBinaryOp<"remui"> {
     Unsigned integer division remainder. Treats the leading bit as the most
     significant, i.e. for `i16`, `6 % -2 = 6 % (2^16 - 2) = 6`.
 
-    Division by zero is undefined behavior. When applied to `vector` and 
-    `tensor` values, the behavior is undefined if _any_ elements are divided by 
+    Division by zero is undefined behavior. When applied to `vector` and
+    `tensor` values, the behavior is undefined if _any_ elements are divided by
     zero.
 
     Example:
@@ -680,8 +680,8 @@ def Arith_RemSIOp : Arith_TotalIntBinaryOp<"remsi"> {
     Signed integer division remainder. Treats the leading bit as sign, i.e. `6 %
     -2 = 0`.
 
-    Division by zero is undefined behavior. When applied to `vector` and 
-    `tensor` values, the behavior is undefined if _any_ elements are divided by 
+    Division by zero is undefined behavior. When applied to `vector` and
+    `tensor` values, the behavior is undefined if _any_ elements are divided by
     zero.
 
     Example:
@@ -794,9 +794,9 @@ def Arith_XOrIOp : Arith_TotalIntBinaryOp<"xori", [Commutative]> {
 def Arith_ShLIOp : Arith_IntBinaryOpWithOverflowFlags<"shli"> {
   let summary = "integer left-shift";
   let description = [{
-    The `shli` operation shifts the integer value of the first operand to the left 
-    by the integer value of the second operand. The second operand is interpreted as 
-    unsigned. The low order bits are filled with zeros. If the value of the second 
+    The `shli` operation shifts the integer value of the first operand to the left
+    by the integer value of the second operand. The second operand is interpreted as
+    unsigned. The low order bits are filled with zeros. If the value of the second
     operand is greater or equal than the bitwidth of the first operand, then the
     operation returns poison.
 
@@ -811,7 +811,7 @@ def Arith_ShLIOp : Arith_IntBinaryOpWithOverflowFlags<"shli"> {
     %1 = arith.constant 5 : i8  // %1 is 0b00000101
     %2 = arith.constant 3 : i8
     %3 = arith.shli %1, %2 : i8 // %3 is 0b00101000
-    %4 = arith.shli %1, %2 overflow<nsw, nuw> : i8  
+    %4 = arith.shli %1, %2 overflow<nsw, nuw> : i8
     ```
   }];
   let hasFolder = 1;
@@ -824,9 +824,9 @@ def Arith_ShLIOp : Arith_IntBinaryOpWithOverflowFlags<"shli"> {
 def Arith_ShRUIOp : Arith_TotalIntBinaryOp<"shrui"> {
   let summary = "unsigned integer right-shift";
   let description = [{
-    The `shrui` operation shifts an integer value of the first operand to the right 
+    The `shrui` operation shifts an integer value of the first operand to the right
     by the value of the second operand. The first operand is interpreted as unsigned,
-    and the second operand is interpreted as unsigned. The high order bits are always 
+    and the second operand is interpreted as unsigned. The high order bits are always
     filled with zeros. If the value of the second operand is greater or equal than the
     bitwidth of the first operand, then the operation returns poison.
 
@@ -848,11 +848,11 @@ def Arith_ShRUIOp : Arith_TotalIntBinaryOp<"shrui"> {
 def Arith_ShRSIOp : Arith_TotalIntBinaryOp<"shrsi"> {
   let summary = "signed integer right-shift";
   let description = [{
-    The `shrsi` operation shifts an integer value of the first operand to the right 
-    by the value of the second operand. The first operand is interpreted as signed, 
-    and the second operand is interpreter as unsigned. The high order bits in the 
-    output are filled with copies of the most-significant bit of the shifted value 
-    (which means that the sign of the value is preserved). If the value of the second 
+    The `shrsi` operation shifts an integer value of the first operand to the right
+    by the value of the second operand. The first operand is interpreted as signed,
+    and the second operand is interpreter as unsigned. The high order bits in the
+    output are filled with copies of the most-significant bit of the shifted value
+    (which means that the sign of the value is preserved). If the value of the second
     operand is greater or equal than bitwidth of the first operand, then the operation
     returns poison.
 
@@ -1229,41 +1229,41 @@ def Arith_ScalingExtFOp
   let summary = "Upcasts input floats using provided scales values following "
                 "OCP MXFP Spec";
   let description = [{
-  This operation upcasts input floating-point values using provided scale 
-  values. It expects both scales and the input operand to be of the same shape, 
-  making the operation elementwise. Scales are usually calculated per block 
+  This operation upcasts input floating-point values using provided scale
+  values. It expects both scales and the input operand to be of the same shape,
+  making the operation elementwise. Scales are usually calculated per block
   following the OCP MXFP spec as described in https://arxiv.org/abs/2310.10537.
 
-  If scales are calculated per block where blockSize != 1, then scales may 
-  require broadcasting to make this operation elementwise. For example, let's 
-  say the input is of shape `<dim1 x dim2 x ... dimN>`. Given blockSize != 1 and 
-  assuming quantization happens on the last axis, the input can be reshaped to 
-  `<dim1 x dim2 x ... (dimN/blockSize) x blockSize>`. Scales will be calculated 
-  per block on the last axis. Therefore, scales will be of shape 
-  `<dim1 x dim2 x ... (dimN/blockSize) x 1>`. Scales could also be of some other 
-  shape as long as it is broadcast compatible with the input, e.g., 
+  If scales are calculated per block where blockSize != 1, then scales may
+  require broadcasting to make this operation elementwise. For example, let's
+  say the input is of shape `<dim1 x dim2 x ... dimN>`. Given blockSize != 1 and
+  assuming quantization happens on the last axis, the input can be reshaped to
+  `<dim1 x dim2 x ... (dimN/blockSize) x blockSize>`. Scales will be calculated
+  per block on the last axis. Therefore, scales will be of shape
+  `<dim1 x dim2 x ... (dimN/blockSize) x 1>`. Scales could also be of some other
+  shape as long as it is broadcast compatible with the input, e.g.,
   `<1 x 1 x ... (dimN/blockSize) x 1>`.
 
-  In this example, before calling into `arith.scaling_extf`, scales must be 
-  broadcasted to `<dim1 x dim2 x dim3 ... (dimN/blockSize) x blockSize>`. Note 
-  that there could be multiple quantization axes. Internally, 
+  In this example, before calling into `arith.scaling_extf`, scales must be
+  broadcasted to `<dim1 x dim2 x dim3 ... (dimN/blockSize) x blockSize>`. Note
+  that there could be multiple quantization axes. Internally,
   `arith.scaling_extf` would perform the following:
- 
+
     ```
-    resultTy = get_type(result) 
+    resultTy = get_type(result)
     scaleTy  = get_type(scale)
     inputTy = get_type(input)
     scale.exponent = arith.truncf(scale) : scaleTy to f8E8M0
     scale.extf = arith.extf(scale.exponent) : f8E8M0 to resultTy
     input.extf = arith.extf(input) : inputTy to resultTy
     result = arith.mulf(scale.extf, input.extf)
     ```
-    It propagates NaN values. Therefore, if either scale or the input element 
+    It propagates NaN values. Therefore, if either scale or the input element
     contains NaN, then the output element value will also be a NaN.
   }];
   let hasVerifier = 1;
   let assemblyFormat =
-      [{ $in `,` $scale (`fastmath` `` $fastmath^)? attr-dict `:` 
+      [{ $in `,` $scale (`fastmath` `` $fastmath^)? attr-dict `:`
       type($in) `,` type($scale) `to` type($out)}];
 }
 
@@ -1373,28 +1373,28 @@ def Arith_ScalingTruncFOp
   let summary = "Downcasts input floating point values using provided scales "
                 "values following OCP MXFP Spec";
   let description = [{
-    This operation downcasts input using the provided scale values. It expects 
-    both scales and the input operand to be of the same shape and, therefore, 
-    makes the operation elementwise. Scales are usually calculated per block 
+    This operation downcasts input using the provided scale values. It expects
+    both scales and the input operand to be of the same shape and, therefore,
+    makes the operation elementwise. Scales are usually calculated per block
     following the OCP MXFP spec as described in https://arxiv.org/abs/2310.10537.
     Users are required to normalize and clamp the scales as necessary before calling
     passing them to this operation.  OCP MXFP spec also does the flushing of denorms
-    on the input operand, which should be handled during lowering by passing appropriate 
-    fastMath flag to this operation. 
-
-    If scales are calculated per block where blockSize != 1, scales may require 
-    broadcasting to make this operation elementwise. For example, let's say the 
-    input is of shape `<dim1 x dim2 x ... dimN>`. Given blockSize != 1 and 
-    assuming quantization happens on the last axis, the input can be reshaped to 
-    `<dim1 x dim2 x ... (dimN/blockSize) x blockSize>`. Scales will be calculated 
-    per block on the last axis. Therefore, scales will be of shape 
-    `<dim1 x dim2 x ... (dimN/blockSize) x 1>`. Scales could also be of some other 
-    shape as long as it is broadcast compatible with the input, e.g., 
+    on the input operand, which should be handled during lowering by passing appropriate
+    fastMath flag to this operation.
+
+    If scales are calculated per block where blockSize != 1, scales may require
+    broadcasting to make this operation elementwise. For example, let's say the
+    input is of shape `<dim1 x dim2 x ... dimN>`. Given blockSize != 1 and
+    assuming quantization happens on the last axis, the input can be reshaped to
+    `<dim1 x dim2 x ... (dimN/blockSize) x blockSize>`. Scales will be calculated
+    per block on the last axis. Therefore, scales will be of shape
+    `<dim1 x dim2 x ... (dimN/blockSize) x 1>`. Scales could also be of some other
+    shape as long as it is broadcast compatible with the input, e.g.,
     `<1 x 1 x ... (dimN/blockSize) x 1>`.
 
-    In this example, before calling into `arith.scaling_truncf`, scales must be 
-    broadcasted to `<dim1 x dim2 x dim3 ... (dimN/blockSize) x blockSize>`. Note 
-    that there could be multiple quantization axes. Internally, 
+    In this example, before calling into `arith.scaling_truncf`, scales must be
+    broadcasted to `<dim1 x dim2 x dim3 ... (dimN/blockSize) x blockSize>`. Note
+    that there could be multiple quantization axes. Internally,
     `arith.scaling_truncf` would perform the following:
 
     ```
@@ -1409,7 +1409,7 @@ def Arith_ScalingTruncFOp
   }];
   let hasVerifier = 1;
   let assemblyFormat =
-      [{ $in `,` $scale ($roundingmode^)? (`fastmath` `` $fastmath^)? attr-dict `:` 
+      [{ $in `,` $scale ($roundingmode^)? (`fastmath` `` $fastmath^)? attr-dict `:`
       type($in) `,` type($scale) `to` type($out)}];
 }