[Mlir-commits] [mlir] Extending UniformQuantizedType with interface-based support for new storage types in Quant dialect (PR #152966)
Anurag Singh
llvmlistbot at llvm.org
Sat Aug 23 08:50:39 PDT 2025
anuragsingh-tt wrote:
> The fundamental issue is that **quantization is a type-level property**, not just an operational detail. When we strip this information from types and relegate it to operation operands, we lose:
Quant-as-type is useful to preserve model intent from a frontend perspective but it is ultimately a numerical transformation eventually lowered to plain ints + params by hardware.
> * Compiler reasoning capabilities
Wouldn't exposing scale/zp as operands increase reasoning opportunities (e.g: CSE, LICM) because they operate on values?
> * Type safety guarantees
This is indeed a plus of the tuple-type approach. Though the guarantees that we can ensure (storage type vs. expressed type legality, axis legal in per channel case, etc.) can still be type parameters?
https://github.com/llvm/llvm-project/pull/152966
More information about the Mlir-commits
mailing list