[Mlir-commits] [mlir] f05b1a2 - [mlir][arith][nfc] Cleanup whitespace in td files (#155109)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Sat Aug 23 12:51:59 PDT 2025
Author: Ivan Butygin
Date: 2025-08-23T22:51:56+03:00
New Revision: f05b1a280656c605deec631e224e7fe1db21bf36
URL: https://github.com/llvm/llvm-project/commit/f05b1a280656c605deec631e224e7fe1db21bf36
DIFF: https://github.com/llvm/llvm-project/commit/f05b1a280656c605deec631e224e7fe1db21bf36.diff
LOG: [mlir][arith][nfc] Cleanup whitespace in td files (#155109)
Added:
Modified:
mlir/include/mlir/Dialect/Arith/IR/ArithBase.td
mlir/include/mlir/Dialect/Arith/IR/ArithOps.td
Removed:
################################################################################
diff --git a/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td b/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td
index e51c20498746b..a3e9fc3c57bb1 100644
--- a/mlir/include/mlir/Dialect/Arith/IR/ArithBase.td
+++ b/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]> {
diff --git a/mlir/include/mlir/Dialect/Arith/IR/ArithOps.td b/mlir/include/mlir/Dialect/Arith/IR/ArithOps.td
index ef9ccb7e87946..20c9097b51e6d 100644
--- a/mlir/include/mlir/Dialect/Arith/IR/ArithOps.td
+++ b/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,28 +1229,28 @@ 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
@@ -1258,12 +1258,12 @@ def Arith_ScalingExtFOp
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)}];
}
More information about the Mlir-commits
mailing list