This is an archive of the discontinued LLVM Phabricator instance.

MinMax Index Pattern Identification
Needs ReviewPublic

Authored by magabari on Jul 14 2016, 12:37 AM.

Details

Summary

[LV] Handling MinMax Index Pattern (part 1)
The following patch is to identify MinMax Pattern in Loop Vectorizer, e.g. :

for ( ... ) {

if(x>cur_max) {
  cur_max = x;
  cur_max_idx = i;
}

}

Currently it support simple induction case with step 1.

Diff Detail

Event Timeline

magabari updated this revision to Diff 63927.Jul 14 2016, 12:37 AM
magabari retitled this revision from to MinMax Index Pattern Identification.
magabari updated this object.
magabari added reviewers: Ayal, delena.
magabari set the repository for this revision to rL LLVM.
magabari updated this revision to Diff 63929.Jul 14 2016, 12:41 AM
magabari removed rL LLVM as the repository for this revision.

small compilation fix in the prev revision

delena edited edge metadata.Jul 14 2016, 5:44 AM

Any test?

magabari updated this revision to Diff 63966.Jul 14 2016, 6:34 AM
magabari edited edge metadata.
magabari set the repository for this revision to rL LLVM.

added test file

Some minor comments inside.

lib/Transforms/Vectorize/LoopVectorize.cpp
4943

Instruction *LoopExit = dyn_cast<SelectInst>(RedDes.getLoopExitInstr());
if (LoopExit ..

4950

A short form:
for (auto reduction_it : Reductions) {

delena added inline comments.
include/llvm/Transforms/Utils/LoopUtils.h
162

line alignment

206

You don't need to check the Kind here - it is just get/set.

lib/Transforms/Utils/LoopUtils.cpp
387

remove {}

424

line alignment

537

The code here is difficult to read. I suggest to separate Select form FCmp and ICmp

540

remove {}

600

What FIX should be done here?

lib/Transforms/Vectorize/LoopVectorize.cpp
4896

Why FP min/max does not require extra verification?

4932

I suggest to take this verification in a separate function.

magabari marked 8 inline comments as done.Jul 18 2016, 7:23 AM
magabari added inline comments.
include/llvm/Transforms/Utils/LoopUtils.h
206

this field not relevant if the Kind != MinMax / MinMaxIdx, i just wrote that assert for sanity check

lib/Transforms/Utils/LoopUtils.cpp
600

its suspected to be a reduction not 100% sure of that.

lib/Transforms/Vectorize/LoopVectorize.cpp
4896

notice that the Index pattern needs the verification not the min\max itself,there is no floatMinMaxIdx type, it's only Integer.

magabari updated this revision to Diff 64316.Jul 18 2016, 7:25 AM
magabari updated this object.
magabari updated this object.Jul 24 2016, 5:46 AM
magabari added reviewers: mkuper, wmi.
mkuper edited edge metadata.Jul 25 2016, 4:37 PM

Two notes, before I start the actual review:

First - next time, please don't add llvm-commits after the patch has already been put up for review.
Rather, cancel the existing review, and start a new one with llvm-commits as a subscriber to begin with. Some people feel strongly about having the patch appear in the review thread on llvm-commits.

Second - is this a complete patch? The "return Maybe; //TODO: FIX" looks fishy. And I didn't see anything actually using the Maybe return value.
If this isn't complete, then I'm not entirely sure what's up for review. In that case, please start a new review with the complete patch - with llvm-commits subscribed from the beginning, per point 1. If it is supposed to be complete, then can you explain what the deal with the Maybe is?
(Breaking a patch into smaller units is generally good - but each such unit should be standalone, and this patch doesn't look like it.)

Two notes, before I start the actual review:

First - next time, please don't add llvm-commits after the patch has already been put up for review.
Rather, cancel the existing review, and start a new one with llvm-commits as a subscriber to begin with. Some people feel strongly about having the patch appear in the review thread on llvm-commits.

Second - is this a complete patch? The "return Maybe; //TODO: FIX" looks fishy. And I didn't see anything actually using the Maybe return value.
If this isn't complete, then I'm not entirely sure what's up for review. In that case, please start a new review with the complete patch - with llvm-commits subscribed from the beginning, per point 1. If it is supposed to be complete, then can you explain what the deal with the Maybe is?
(Breaking a patch into smaller units is generally good - but each such unit should be standalone, and this patch doesn't look like it.)

Regarding your first point Okay.
Second point: This is part 1 from 2 this patch deals with the identification of Min Max Index pattern only (it won't vectorize it) although it's a standalone commit but i think i will wait and commit both parts together.
The "Maybe" is just a bad name, need to understand that MinMax Index Pattern rely on the fact that we have found MinMax pattern, so in the first phase i can only say that its a good candidate for MinMax Index reduction (this is why i return Maybe i think it's better to return Candidate) and i put this in ExtraVerificationRequiredList to verify that we have found Min Max pattern. In the 2nd phase i move over all those candidates and make sure that they are real reductions.

The problem is that as long as the Yes/No/Maybe interface doesn't get used, it's really hard to understand whether it makes sense.
There may be a better way to handle this, and it's really hard to know without seeing the use.

In this case, I suggest you post a more complete patch (for a new review, with llvm-commits subscribed), even if thought it'll be larger.
Also, please clang-format the code you're adding before you post the patch for review. There are a lot of 80-column violations here, among other things.

Is this still alive?