We often have constraints for array attributes that they are sorted
non-decreasing or strictly increasing. This change adds AttrConstraint classes
that support DenseArrayAttr for integer types.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Sorry for the many updates for this patch, I should have self-reviewed everything before uploading. But I have finished self-review now, so it should be ready to take a look now.
This AttrConstr is planned to be used for Linalg ReduceOp:
ConfinedAttr<DenseI64ArrayAttr, [ArrayStrictlySorted<64>]>:$dimensions
But it seems likely to be useful in other cases as well.
Should I add this usage in this patch, or in a separate one?
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1639 | Sorry, accepted too quickly, this feels a bit wonky .. Can we use the full type instead of just the number of bits? ConfinedAttr<DenseI16ArrayAttr, ArraySorted<DenseI16ArrayAttr>> just 16 looks very surprising to use here. |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1639 | The naming on these looks off, Array by itself should only be used for ArrayAttr (this is DenseArrayAttr). +1 also on not just using bitwidth, the context is not obvious enough here. |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1639 | I am now using DenseArraySorted/DenseArrayStrictlySorted as names. |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1639 | You could use arrayType.returnType instead of ArrayRef<" # elementType # "> to get rid of the element type parameter. The returnType of DenseArrayAttrBase is always an ArrayRef of the element type which happens to be what you need. |
Use arrayType.returnType
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1639 | Thank you very much :) |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1645 | I think you should be able to use is_sorted with a comparator here ? (i.e. always return false if elements are equal) |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1645 | TLDR: Technically, it seems using the std::less_equal comparator should work. I was not sure whether we can rely on the way the comparator will be used. The documentation says you need to pass a "less" comparator. But then it also defines sorted as: A sequence is sorted with respect to a comparator comp if for any iterator it pointing to the sequence and any non-negative integer n such that it + n is a valid iterator pointing to an element of the sequence, comp(*(it + n), *it) evaluates to false. If implemented like that, using std::less_equal would definitely work. Also I see that boost uses std::less_equal to implement is_strictly_increasing. But I think this would mean that I need another parameter to the DenseArrayStrictlySorted constraint: the element type, so that I can specify the comparator. Or is there a way to derive that from DenseArrayAttrBase? |
mlir/include/mlir/IR/OpBase.td | ||
---|---|---|
1645 | If it is not possible to use some auto type deduction based on the result of asArrayRef we could always make the cppType available from DenseArrayAttrBase. |
Sorry, accepted too quickly, this feels a bit wonky ..
Can we use the full type instead of just the number of bits?
ConfinedAttr<DenseI16ArrayAttr, ArraySorted<DenseI16ArrayAttr>>
just 16 looks very surprising to use here.