Lowering arith.maxf/minf to __nv_fmax/__nv_fmin in GPUToNVVM Conversion.
Also remove Linalg pass declaration which is not cleaned.
Details
- Reviewers
ThomasRaoux herhut nicolasvasilache
Diff Detail
Event Timeline
| mlir/include/mlir/Dialect/Linalg/Passes.h | ||
|---|---|---|
| 34 | Is this on purpose? | |
| mlir/include/mlir/Dialect/Linalg/Passes.h | ||
|---|---|---|
| 34 | never mind I see your comment and this is dead. | |
| mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
| 257 | The semantic of arith::MaxFOp and __nv_fmax_f are different for Nan values: arith::MaxFOp: Returns the maximum of the two arguments, treating -0.0 as less than +0.0. If one of the arguments is NaN, then the result is also NaN. __nv_fmax_f: If one argument is a NaN and the other is legitimate numeric value, the numeric value is chosen. | |
| mlir/include/mlir/Dialect/Linalg/Passes.h | ||
|---|---|---|
| 34 | this pass seems to be removed at https://reviews.llvm.org/D124145 | |
| mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
|---|---|---|
| 257 | This seems to be a problem. BTW, does other math function have the same problem? like math.sin(NaN) and __nv_sin(NaN). | |
| mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
|---|---|---|
| 257 | Yes I don't think we can have this lowering with the current semantic of arith::MaxFOp as far as I know this problem is only for fmax/fmin as the semantic of TF and other ML framework tends to be different than what hw natively support. For other arithmetic operations the semantic is more obvious. | |
| mlir/include/mlir/Dialect/Linalg/Passes.h | ||
|---|---|---|
| 34 | Thanks! | |
| mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
|---|---|---|
| 257 | Thanks, should I close this differential? | |
| mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
|---|---|---|
| 257 | Yes unfortunately I don’t think there is another solution right now. | |
Is this on purpose?