This is an archive of the discontinued LLVM Phabricator instance.

Generate `arith.{floordivsi,ceildivsi}` in lowering affine exprs
AbandonedPublic

Authored by Benoit on Dec 14 2022, 11:40 AM.

Details

Summary

It seems that the existing lowerings must have predated the introduction of arith.{floordivsi,ceildivsi}, requiring a custom implementation based on arith.divsi and several other ops to implement the floor/ceil aspects?

My immediate motivation for this is that the existing code had to check if the RHS was positive, and it could only do so when the RHS was constant, so it required it to be constant, and I have a use case where it's dynamic, so I ran into the error there.

Looking at the tests, I saw the comment pointing to the corresponding canonicalize.mlir testcase (actually the comment mentioned another file name but the testcase moved, so this PR fixes that). But then looking at the canonicalize.mlir testcase, it seems that its existence was justified by the complex IR that used to be produced, and now that it's a single arith op, no canonicalize.mlir testcase is needed anymore. So this PR also removes that.

Diff Detail

Event Timeline

Benoit created this revision.Dec 14 2022, 11:40 AM
Benoit requested review of this revision.Dec 14 2022, 11:40 AM
Benoit retitled this revision from Generate arith.{floordivsi,ceildivsi} in lowering affine exprs to Generate `arith.{floordivsi,ceildivsi}` in lowering affine exprs.Dec 14 2022, 11:45 AM
Benoit edited the summary of this revision. (Show Details)
Benoit updated this revision to Diff 482963.Dec 14 2022, 12:32 PM

Expand floordivsi/ceildivsi to avoid breaking downstream patterns not expecting those
(caught by e2e compilation tests in IREE).

Benoit updated this revision to Diff 482964.Dec 14 2022, 12:35 PM

clang-format

dcaballe added inline comments.Dec 14 2022, 12:36 PM
mlir/test/Transforms/canonicalize.mlir
616

can we regenerate the IR from affine.apply affine_map<(i) -> (i mod 42)> and make sure that canonicalization is still happening?

I checked, the checked IR in lower-affine.mlir for affine_apply_mod still matches what canonicalize.mlir checks in lowered_affine_mod .

dcaballe accepted this revision.Dec 14 2022, 12:47 PM

Great! Could you please move the canonicalization tests to test/Dialect/Arith/canonicalize.mlir using the new floor/ceil ops? Other than that, LGTM. Thanks!

mlir/test/Transforms/canonicalize.mlir
616

I guess if we have a similar folding test for the floor/ceil div ops, that should be enough. If you can check if that is the case, that should be all!

This revision is now accepted and ready to land.Dec 14 2022, 12:47 PM
Benoit abandoned this revision.Dec 14 2022, 1:44 PM

Dropping this Review. I realized that the lowering (by ExpandOps.cpp) of arith.floordivsi to arith.divsi unconditionally generates 2 divisions. The branch-free lowering approach there is misfiring --- it's great to be branch-free, but not if that means 2x more divisions, as these days divisions (with non-constant RHS) are far more expensive than some branching inside some arithmetic. I will instead work on removing my code's reliance on affine floordiv/ceildiv.