[Mlir-commits] [mlir] [mlir][python] Add bindings for mlirDenseElementsAttrGet (PR #91389)

[Oleksandr Alex Zinenko]

ftynse wrote:

> Out of curiosity, what was the intended purpose of `mlirDenseElementsAttrGet` if creating attributes is expensive? Or is that only true in Python?

To replicate the API existing in C++: `DenseElementsAttr::get(ShapedType type, ArrayRef<Attribute> values)`, we needed proof-of-life for the attribute, nothing more. It may be useful when the caller already has attributes for elements, but is discouraged when they have to construct those only to construct the elements attribute.

> Or is there already infrastructure to convert Python numbers?

It is possible to construct these attributes from an object implementing the Python buffer protocol, e.g., `DenseI64ElementsAttr.get(array.array('q', [1,2,3]))` works, though most people go through `numpy.array`.

> Also, is there any value in allowing existing attributes to be packed into a DenseElementsAttr? i.e. should I keep this PR open at all? Maybe it's worth having it just for the sake of parity between the C/Python APIs.

It's okay to add if there is a use case. I would rather not add code nobody uses, that only increases the maintenance load.

> With that said, I don't think what you are proposing hurts anything. I'd probably draw the line if it required C API changes as not being worth it.

I won't object to there being `mlirDenseI64ElementsAttrGet(MlirType shapedType, int64_t *elements, int64_t numElements)`, `mlirDenseBoolElementsAttrGet(MlirType shapedType, bool *elements, int64_t numElements)`, etc. if there is a client for those. Assuming they don't already exist.


https://github.com/llvm/llvm-project/pull/91389