[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