Page MenuHomePhabricator

Extended LoadStoreVectorizer to vectorize subchains.
ClosedPublic

Authored by asbirlea on Jul 7 2016, 4:20 PM.

Details

Summary

LSV used to abort vectorizing a chain for interleaved load/store accesses that alias.
Allow a valid prefix of the chain to be vectorized, mark just the prefix and retry vectorizing the remaining chain.

Diff Detail

Event Timeline

asbirlea updated this revision to Diff 63158.Jul 7 2016, 4:20 PM
asbirlea retitled this revision from to Extended LoadStoreVectorizer to vectorize subchains..
asbirlea updated this object.
asbirlea added reviewers: llvm-commits, jlebar, arsenm.
jlebar added inline comments.Jul 7 2016, 6:42 PM
lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
108–109

Please update comment.

109–115

This probably also deserves a new name.

443

Suppose we have

  • load
  • load
  • fn_with_side_effects
  • load

Don't we want to (try to) vectorize the first two loads? Or, do you want to handle that in a separate patch?

449–450

Nit, I'm not wild about reusing "Idx" for something different. (I mean, it's still an index, but over a completely different list.)

665

Calling this param "FullChain" is weird, since when we call this recursively, we pass what I can only call a partial chain. :)

698–708

Is "VectorizedSet" the right name? In this case we're saying that we didn't vectorize anything (and we're returning false), yet we're adding these instructions to the set...

701

If this is just describing the call to getBoundaryInstrs, I don't think it needs a comment. If it's describing something else, can we reword it? I don't think "enclosing" is the right word. Maybe "Get the first and last instructions in FullChain," but that's basically exactly what getBoundaryInstrs' comment says.

704

Nit, end sentences with periods.

711

This indentation is very confusing. I think it would be OK to put the comment inside the "else"? In which case I'd suggest also putting braces (although some folks around here would leave them out, which really mystifies me).

713

VectorizedSet->push_back(FullChain.front());

715

I think this would be clearer as two separate if statements (repeating the "return false"). I'd rather repeat one short line than add an extra level of nesting.

if (StopChain == 0) {
  // No vectorization possible, bail out.
  VectorizedSet->append(...);
  return false;
}
if (StopChain == 1) {
  // Failed after the first instruction.  Discard it and try the smaller chain.
  VectorizedSet->push_back(FullChain.front());
  return false;
}
749

"discarded for future vectorization" is awkward. Maybe "We won't try again to vectorize the elements of chain, regardless of whether we succeed below."

asbirlea updated this revision to Diff 63359.Jul 8 2016, 5:13 PM

Address comments.

jlebar added inline comments.Jul 8 2016, 10:55 PM
lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
443

Did you intend to address this comment in your latest update?

asbirlea added inline comments.Jul 11 2016, 7:31 AM
lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
443

No, let's handle that in a separate patch. Yes, it's another feature that should be added.

jlebar added inline comments.Jul 11 2016, 10:45 AM
lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
111

The first sentence in this comment no longer really applies. Can we make this more cohesive?

112

Per IRL, maybe vectorizablePrefixEnd or vectorizablePrefixEndIdx would be a better name?

357

Hm, why is this diff showing up here? Shouldn't this be part of D22071?

449–450

Well, calling the one "Idx" and the other "Index" doesn't entirely solve the problem of using the same name for the two variables. Now they're different names to the computer, but still basically the same name to humans. :)

How about InstrIdx and ChainIdx? Then you could rename VIdx to InstrIdx, which would be a plus for readability, I think (since these *are* the same indices). (The problem with s/Idx/VIdx/ is that the first loop is really over instructions, not Values.)

627–636

Capital letters for variables. Although, why did we lose the range-based for loop in the first place? Was it just so we could do Head = -1? If so, a flag variable would be much more clear, I think.

659

We shouldn't need a separate variable for this. Can we just pass VectorizedValues (needs to be renamed) to vectorizeLoadChain directly (after changing the type accepted by that function)?

asbirlea updated this revision to Diff 63605.Jul 11 2016, 3:59 PM

Update to latest.

asbirlea updated this revision to Diff 63745.Jul 12 2016, 4:01 PM

Address comments.

asbirlea marked 6 inline comments as done.Jul 12 2016, 4:08 PM
asbirlea added inline comments.
lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
111

Well, it still applies. It's still checking for the existance of those instructions but using the info differently. I shortened the comment somewhat.

357

Because I accidentally did the updates on this one some time ago :). Then I redid them on the other one.

449–457

Also updated VV/V and VVIdx/VIdx. They still need different names from InstrIndx, since the same index is used for both Chain and Mem in the loop above, and now we need two.

627–637

For Heads it's fine to use the range-based loop (updated). For Tails I need the iterator to get Heads[TailsIterator].

jlebar accepted this revision.Jul 12 2016, 4:34 PM
jlebar edited edge metadata.
jlebar added inline comments.
lib/Transforms/Vectorize/LoadStoreVectorizer.cpp
111

I like it now. :)

Except we should be consistent *at least within a single comment* as far as whether we're using indicative ("checks") or imperative ("return").

435

Do we need to declare E? Can we just say I != To?

465

Please be sure to clang-format the lines you've touched in this patch (e.g. with git-clang-format HEAD^) before submitting.

627–637

OK. I would still very much prefer to use a separate flag variable rather than repurposing Head for that purpose, though.

This revision is now accepted and ready to land.Jul 12 2016, 4:34 PM
asbirlea updated this revision to Diff 63755.Jul 12 2016, 4:44 PM
asbirlea marked 4 inline comments as done.
asbirlea edited edge metadata.

Address comments.

This revision was automatically updated to reflect the committed changes.