This was incorrectly left and merged with #160615
When executed in the context of canonicalization, the folders are invoked in a fixed-point iterative process. However in the context of an API like `createOrFold()` or in DialectConversion for example, we expect a "one-shot" call to fold to be as "folded" as possible. However, even when folders themselves are indempotent, folders on a given operation interact with each other. For example: ``` // X = 0 + Y %X = arith.addi %c_0, %Y : i32 ``` should fold to %Y, but the process actually involves first the folder provided by the IsCommutative trait to move the constant to the right. However this happens after attempting to fold the operation and the operation folder isn't attempt again after applying the trait folder. This commit makes sure we iterate until fixed point on folder applications. Fixes #159844
This is the first patch to add support for the SPV_ARM_graph SPIR-V extension to MLIR’s SPIR-V dialect. The extension introduces a new Graph abstraction for expressing dataflow computations over full resources. The part 1 implementation includes: - A new `GraphType`, modeled similarly to `FunctionType`, for typed graph signatures. - New operations in the `spirv.arm` namespace: - `spirv.arm.Graph` - `spirv.arm.GraphEntryPoint` - `spirv.arm.GraphConstant` - `spirv.arm.GraphOutput` - Verifier and VCE updates to properly gate usage under SPV_ARM_graph. - Tests covering parsing and verification. Graphs currently support only SPV_ARM_tensors, but are designed to generalize to other resource types, such as images. Spec: KhronosGroup/SPIRV-Registry#346 RFC: https://discourse.llvm.org/t/rfc-add-support-for-spv-arm-graph-extension-in-mlir-spir-v-dialect/86947 --------- Signed-off-by: Davide Grohmann <davide.grohmann@arm.com>
This PR adds `arith.scaling_truncf` and `arith.scaling_extf` operations which supports the block quantization following OCP MXFP specs listed here https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf OCP MXFP Spec comes with reference implementation here https://github.com/microsoft/microxcaling/tree/main Interesting piece of reference code is this method `_quantize_mx` https://github.com/microsoft/microxcaling/blob/7bc41952de394f5cc5e782baf132e7c7542eb4e4/mx/mx_ops.py#L173. Both `arith.scaling_truncf` and `arith.scaling_extf` are designed to be an elementwise operation. Please see description about them in `ArithOps.td` file for more details. Internally, `arith.scaling_truncf` does the `arith.truncf(arith.divf(input/(2^scale)))`. `scale` should have necessary broadcast, clamping, normalization and NaN propagation done before callling into `arith.scaling_truncf`. `arith.scaling_extf` does the `arith.mulf(2^scale, input)` after taking care of necessary data type conversions. CC: @krzysz00 @dhernandez0 @bjacob @pashu123 @MaheshRavishankar @tgymnich --------- Co-authored-by: Prashant Kumar <pk5561@gmail.com> Co-authored-by: Krzysztof Drewniak <Krzysztof.Drewniak@amd.com>
When illegal (and not legalizable) constant operations are materialized during a dialect conversion as part of op folding, these operations must be deleted again. This used to be implemented via the rollback mechanism. This commit switches the implementation to regular rewriter API usage: simply delete the materialized constants with `eraseOp`. This commit is in preparation of the One-Shot Dialect Conversion refactoring, which will disallow IR rollbacks. This commit also adds a new optional parameter to `OpBuilder::tryFold` to get hold of the materialized constant ops.
This is a small QoL improvement so that we don't have to go through helpers when building `NamedAttribute`s.
Remove builder API (e.g., `b.getFloat4E2M1FNType()`) and caching in `MLIRContext` for low-precision FP types. Types are still cached in the type uniquer. For details, see: https://discourse.llvm.org/t/rethink-on-approach-to-low-precision-fp-types/82361/28 Note for LLVM integration: Use `b.getType<Float4E2M1FNType>()` or `Float4E2M1FNType::get(b.getContext())` instead of `b.getFloat4E2M1FNType()`.
This commit removes convenience methods from `FloatType` to make it independent of concrete interface implementations. See discussion here: https://discourse.llvm.org/t/rethink-on-approach-to-low-precision-fp-types/82361 Note for LLVM integration: Replace `FloatType::getF32(` with `Float32Type::get(` etc.
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
I'm not touching PointerUnion::dyn_cast for now because it's a bit
complicated; we could blindly migrate it to dyn_cast_if_present, but
we should probably use dyn_cast when the operand is known to be
non-null.