Consecutive tosa.abs can be fold as single abs operation since the second one has no impact.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks good!
In general, MLIR could have an Idempotence trait on ops and then a general facility in the folder.
In TOSA specifically, I think also floor, ceil and clamp (with same min/max) are idempotent.
Funny you should mention that
https://mlir.llvm.org/doxygen/classmlir_1_1OpTrait_1_1IsIdempotent.html
@mgehre-amd @jpienarr Okay. I’ll add the IsIdempotent trait for these ops in a separate change. Thanks!
In TOSA specifically, I think also floor, ceil and clamp (with same min/max) are idempotent.
Idempotent trait seems to expect the op not to change the type itself. They cannot be applied to these ops as it is.
static_assert failed due to requirement 'CeilOp::hasTrait()' "expected operation to preserve type"
I think the issue is that floor/ceil/clamp don't have the SameOperandsAndResultType trait which is required by the Idempotent trait. It should be okay to add for floor/ceil/clamp as they shouldn't change type.
We can't add SameOperandsAndResultType to the TOSA elementwise binary operators because of the implicit broadcast in TOSA. In those cases the difference in shape between the input and output would cause failures. (Not a factor here, but noting it for reference)
We can't put Idempotent on clamp because the Idempotent fold operation doesn't check the attributes, so could potentially fold improperly. It likely needs an op specific folder.