[Mlir-commits] [mlir] [MLIR] Let matchers work on int ranges (PR #102494)

Christian Ulmann llvmlistbot at llvm.org
Tue Aug 13 02:10:46 PDT 2024


Dinistro wrote:

> One way to make the change more opt in could be that we either add a new interface (i.e. a StaticIntRangeInterface or similar) that implements a `getStaticResultBounds` function that returns the static upper and lower bounds for the result of an operation (not taking the operands into account). Potentially that function could also be added to the existing interface, providing a default implementation that returns std::nullopt instead of a constant range.

Duplicating the interface logic for this one matcher seems overkill. In the end, we would want this to be implemented almost everywhere possible.

> An alternative way could be to add a speculatable attribute on the division operation which if set makes the division speculatable. That way downstream passes could use potentially more complex analysis to decide if a division is speculatable.

I don't think that this is safe in the general case. Transformations need to be aware of this and strip this, which is not desirable. 

> Let me know if you have any preference?

I think that the current implementation is acceptable. While there is a slight constant overhead, this will only be relevant for users of this matcher, i.e., the division operation.

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


More information about the Mlir-commits mailing list