This is an archive of the discontinued LLVM Phabricator instance.

[tests] precommit tests for D136015
ClosedPublic

Authored by Allen on Oct 20 2022, 5:21 AM.

Diff Detail

Event Timeline

Allen created this revision.Oct 20 2022, 5:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 5:21 AM
Allen requested review of this revision.Oct 20 2022, 5:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 5:21 AM
spatel added inline comments.Oct 20 2022, 6:33 AM
llvm/test/Transforms/InstCombine/mul.ll
1587–1588 ↗(On Diff #469179)

In all of the tests with no extra uses, we are able to reduce the patterns to use the unmasked in0/in1 rather than In0Lo/In1Lo.

To get better test coverage, we need more variety of the patterns that actually use the Lo values, so add extra uses to more of these tests to exercise those cases.

You can vary the types (wider, narrower, vectors) in this set of 16 tests, so we don't need extra tests specifically for different types.

1695 ↗(On Diff #469179)

We can see that the commuted instruction is not actually tested because it changed. You'll need to add something (extra uses?) to make sure the tests are providing the coverage for the expected pattern.

Allen added a subscriber: RKSimon.Oct 20 2022, 8:46 AM
Allen added inline comments.
llvm/test/Transforms/InstCombine/mul.ll
1587–1588 ↗(On Diff #469179)

Now the following pattern can't be addressed with D136015, it need more work to match, maybe just as @RKSimon said in https://reviews.llvm.org/D136015#inline-1314325, so I hope this can be fixed out later with a separate patch?

define i64 @mul64_low_A0_B0(i64 noundef %in0, i64 noundef %in1) {
  %In0Hi = lshr i64 %in0, 32
  %In1Hi = lshr i64 %in1, 32
  %m10 = mul i64 %In1Hi, %in0
  %m01 = mul i64 %in1, %In0Hi
  %m00 = mul i64 %in1, %in0
  %addc = add i64 %m10, %m01
  %shl = shl i64 %addc, 32
  %addc9 = add i64 %shl, %m00
  ret i64 %addc9
}
spatel added inline comments.Oct 20 2022, 10:34 AM
llvm/test/Transforms/InstCombine/mul.ll
1587–1588 ↗(On Diff #469179)

I don't understand this comment. The example you show here should not be reduced:
https://alive2.llvm.org/ce/z/JLmNU5

If can remove the and from these patterns completely (because the high bits are known zero), then we should also be able to remove the lshr (because the result must be zero).

So include that as a negative test? We should also have negative tests where the shift amount is not exactly half width and the mask value is not exactly half width.

Allen updated this revision to Diff 469461.Oct 20 2022, 8:34 PM
Allen marked an inline comment as done.

a) Add case with extra use to exercise those cases
b) Add some more negitive test cases and todo cases

Allen marked 2 inline comments as done.Oct 20 2022, 9:28 PM
Allen added inline comments.
llvm/test/Transforms/InstCombine/mul.ll
1587–1588 ↗(On Diff #469179)

Thanks for your suggestion, and apply your comment with extra uses
Add new negative case mul64_low_no_and, mul16_low_miss_shift_amount and mul8_low_miss_half_width

1695 ↗(On Diff #469179)

Add extra uses for all 16 cases of variety types, thanks

spatel added inline comments.Oct 21 2022, 5:52 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
46

Remove the extra use of the return value in all tests - that does not change anything for the transform.

73

I think it would be better to not have extra uses of both hi-lo muls in all of the tests. Just keep the extra uses in half of the tests?

We want to have some coverage for both cases: the mul uses the Lo value, or the mul uses the full in0/in1 directly.

Allen updated this revision to Diff 469839.Oct 21 2022, 6:19 PM
Allen marked 2 inline comments as done.

a) The 1st half tests have extra uses of both hi-lo muls to use the Lo value, and the 2nd half have no extra uses to uses the full in0/in1 directly.
b) delete all the extra use of the return value

Allen marked an inline comment as done.Oct 21 2022, 6:20 PM
Allen added inline comments.
llvm/test/Transforms/InstCombine/mul_fold.ll
46

Done, thanks

73

Done, thanks

Allen updated this revision to Diff 469841.Oct 21 2022, 6:21 PM
Allen marked an inline comment as done.
spatel added inline comments.Oct 22 2022, 4:50 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
304

This extra use means we are still using In0Lo and In1Lo in the multiplies. The test comment above says this and the following tests should not be doing this?
"the 2nd half have no extra uses to uses the full in0/in1 directly"

763

typo: remove the "add"

Allen added inline comments.Oct 22 2022, 5:22 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
304

so update with "the 2nd half have no extra uses of mul to uses the full in0/in1 directly" to avoid the conflict ?

Allen updated this revision to Diff 469885.Oct 22 2022, 5:34 AM

update some comment

spatel added inline comments.Oct 22 2022, 5:56 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
304

No.

There are 4 variations of the partial multiplies: Hi/Lo and Hi/Lo, Hi/In and Hi/Lo, Hi/Lo and Hi/In, Hi/In and Hi/In.

The tests should be in canonical form to start - we do not want to rely on some other transform to produce the expected pattern for test.

Here are 2 examples of the tests and output that I expect to see:
https://alive2.llvm.org/ce/z/C6ocXQ

We also want to test 16 commuted variations, so give each Hi/Lo variation 4 different commuted tests for maximum test coverage? If we want to be really thorough, we could just copy all of these patterns and get 16 * 4 = 64 tests, but I don't think that is necessary.

spatel added inline comments.Oct 22 2022, 6:00 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
304

Sorry - I messed up the shift amounts when narrowing the width in those examples. Use this link instead:
https://alive2.llvm.org/ce/z/MkTpYs

Allen added inline comments.Oct 22 2022, 6:36 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
304

So I try to copy the 16 cases, delete the use of call void @use32(i32 [[ADDC]]) and keep one use of mul similar as your link https://alive2.llvm.org/ce/z/MkTpYs**
i.e. one half only use
%m10 , and the other half only use %m01** ? Does it enough? (we already have cases with no uses of mull and case with 2 uses of mull)

spatel added inline comments.Oct 22 2022, 7:35 AM
llvm/test/Transforms/InstCombine/mul_fold.ll
304

I don't understand the question. I'd have:

  1. 4 tests that use in0/in1 with different commutes
  2. 4 tests that use in0/In1Lo with different commutes
  3. 4 tests that use In0Lo/in1 with different commutes
  4. 4 tests that use In0Lo/In1Lo with different commutes

I'd vary the types across those 16 tests to include at least one vector type and one wide type, and that should provide coverage for all of the patterns that we are trying to fold.

Allen updated this revision to Diff 469903.Oct 22 2022, 8:03 AM

4 tests that use in0/in1 with different commutes
4 tests that use in0/In1Lo with different commutes
4 tests that use In0Lo/in1 with different commutes
4 tests that use In0Lo/In1Lo with different commutes

Allen marked 4 inline comments as done.Oct 22 2022, 8:13 AM
Allen added inline comments.
llvm/test/Transforms/InstCombine/mul_fold.ll
304

As the initial version doesn't support the vector type and wide type, so I only add TODO cases for that (mul_v2i8_low and mul130_low), I'll add new cases with extra use in a follow-up patch when they are supported ?

Allen updated this revision to Diff 469905.Oct 22 2022, 8:21 AM
  • update the CHECK-NEXT with update_test_checks.py

llvm/utils/update_test_checks.py --opt-binary=/e/source/llvm-project/build/bin/opt.exe llvm/test/Transforms/InstCombine/mul_fold.ll

Allen updated this revision to Diff 469962.Oct 22 2022, 10:37 PM

Add extra 2 cases (@mul130_low_one_extra_user and @mul_v2i8_low_one_extra_user) to coverage for the wide/vector types

Allen marked an inline comment as done.Oct 22 2022, 11:27 PM
Allen added inline comments.
llvm/test/Transforms/InstCombine/mul_fold.ll
304

Thanks for patient, I added extra two cases for vector/wide types (@mul130_low_one_extra_user and @mul_v2i8_low_one_extra_user)

spatel accepted this revision.Oct 23 2022, 5:37 AM

This doesn't answer my request ("The tests should be in canonical form to start - we do not want to rely on some other transform to produce the expected pattern for test.").
But go ahead and push this, and we can make adjustments as a follow-up quicker than continuing this review.

This revision is now accepted and ready to land.Oct 23 2022, 5:37 AM
This revision was landed with ongoing or failed builds.Oct 23 2022, 6:41 AM
This revision was automatically updated to reflect the committed changes.