This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][Arith] Fold repeated xor and trunc
ClosedPublic

Authored by wsmoses on Dec 29 2021, 11:31 AM.

Details

Summary

This patch adds two folds. One for a repeated xor (e.g. xor(xor(x, a), a)) and one for a repeated trunc (e.g. trunc(trunc(x))).

Diff Detail

Event Timeline

wsmoses created this revision.Dec 29 2021, 11:31 AM
wsmoses requested review of this revision.Dec 29 2021, 11:31 AM
mehdi_amini added inline comments.Dec 29 2021, 12:01 PM
mlir/lib/Dialect/Arithmetic/IR/ArithmeticCanonicalization.td
117 ↗(On Diff #396558)

We should match any constant instead of directly Arith_ConstantOp, but more importantly I think that a reassociation like A(B(x, c0), c1) = A(x, B(c1, c2)) deserves to be generic and implemented with a "reassociative" trait.

147 ↗(On Diff #396558)

Seems like this could be a fold?
Fold is allowed to mutate the current op in-place instead of returning a constant.

wsmoses updated this revision to Diff 397925.Jan 6 2022, 10:07 AM

Change to folders

wsmoses updated this revision to Diff 397929.Jan 6 2022, 10:14 AM

Fix rebase error

wsmoses retitled this revision from [MLIR][Arith] Canonicalize repeated xor and trunc to [MLIR][Arith] Fold repeated xor and trunc.Jan 6 2022, 10:47 AM
wsmoses edited the summary of this revision. (Show Details)
ftynse accepted this revision.Jan 7 2022, 12:29 AM

This more focused version LGTM. The "Reassociative" trait suggested by Mehdi is still interesting as a separate patch.

This revision is now accepted and ready to land.Jan 7 2022, 12:29 AM
This revision was automatically updated to reflect the committed changes.

Updated version LGTM as well :)

Can you please address these? Looks like these were missed by other reviewers.

mlir/lib/Dialect/Arithmetic/IR/ArithmeticOps.cpp
866–867

We shouldn't be checking things that are guaranteed by the op's verifier. It's unnecessary and would lead to a bloat if done consistently.

875–876

This is leading to a redundant call to getDefiningOp -- there isn't a benefit to using matchPattern here. Just use getDefiningOp<arith::TruncIOp>() -- eliminates an extra check.