This is an archive of the discontinued LLVM Phabricator instance.

[LoopAccessAnalysis] Recognize geps that include s/zexts as consecutive memory accesses.
AbandonedPublic

Authored by bmakam on Aug 24 2016, 3:19 PM.

Details

Summary

We have two versions of isConsecutiveAccess() in tree. The instance in the LoopAccessAnalysis is used to drive the SLP vectorizer
and to some degree the Loop Idiom Recognition pass. The other instance was recently committed with the LoadStoreVectorizer,
which has additional logic to deal with gep patterns that include zexts and sexts. This is useful to figure out that accesses
A[3*i], A[3*i+1] and A[3*i+2] are consecutive which SCEV currently fails to recognize.

This patch ports the additional logic from the LoadStoreVectorizer and merges the two versions into the LoopAccessAnalysis version.

Contributed-by: Chad Rosier <mcrosier@codeaurora.org>

Diff Detail

Event Timeline

bmakam updated this revision to Diff 69175.Aug 24 2016, 3:19 PM
bmakam retitled this revision from to [LoopAccessAnalysis] Recognize geps that include s/zexts as consecutive memory accesses..
bmakam updated this object.
bmakam added a reviewer: mcrosier.
bmakam added a subscriber: llvm-commits.
bmakam updated this object.Aug 24 2016, 3:32 PM
mssimpso edited edge metadata.Aug 25 2016, 7:45 AM

Balaram,

Here's a quick question before I start looking at the details. Won't we still have two implementations of isConsecutiveAccess after this change? Is something preventing us from replacing LoadStoreVectorizer::isConsecutiveAccess with llvm::isConsecutiveAccess?

Balaram,

Here's a quick question before I start looking at the details. Won't we still have two implementations of isConsecutiveAccess after this change? Is something preventing us from replacing LoadStoreVectorizer::isConsecutiveAccess with llvm::isConsecutiveAccess?

No. I will remove the implementation in LoadStoreVectorizer as a follow up patch if this looks good.

The logic looks fine, but I'm wondering if it makes sense to add this functionality directly into SCEV? It might be beneficial to transformations other than SLP and LoopIdiom. What do you think?

lib/Analysis/LoopAccessAnalysis.cpp
1112

It's probably not a big deal, but this part makes me wonder about compile-time a little. In SLP, for example, we can call isConsecutiveAccess in an N^2 algorithm (e.g., when we try and sort a set of stores). Is computeKNownBits smart about caching results or does it always traverse the expression tree?

It may be rare that we ever reach this code, though.

bmakam updated this revision to Diff 69694.Aug 30 2016, 8:34 AM
bmakam updated this object.
bmakam edited edge metadata.

Merge the two versions of isConsecutiveAccess into LoopAccessAnalysis and remove the implementation in LoadStoreVectorizer.

The logic looks fine, but I'm wondering if it makes sense to add this functionality directly into SCEV? It might be beneficial to transformations other than SLP and LoopIdiom. What do you think?

Matt, I agree with you in principle but I do not have enough understanding of how SCEV works and after my first time reading through SCEV analysis I do not know how involved it is to add this functionality directly into SCEV.

bmakam added inline comments.Aug 30 2016, 8:38 AM
lib/Analysis/LoopAccessAnalysis.cpp
1112

I think it is very rare we ever reach this code. In my testing on spec2k* I did not find any instance.

mcrosier edited edge metadata.Aug 30 2016, 9:04 AM

The logic looks fine, but I'm wondering if it makes sense to add this functionality directly into SCEV? It might be beneficial to transformations other than SLP and LoopIdiom. What do you think?

Matt, I agree with you in principle but I do not have enough understanding of how SCEV works and after my first time reading through SCEV analysis I do not know how involved it is to add this functionality directly into SCEV.

I'm not opposed to leaving this as is (i.e., not enhancing SCEV). My main goal was to remove the redundant code in the LoadStoreVectorizer.

lib/Analysis/LoopAccessAnalysis.cpp
1112

Balaram,
Do you mean you added an assertion to make sure we never hit this code or that you didn't see any codegen changes for SPEC200X?

bmakam added inline comments.Aug 30 2016, 9:13 AM
lib/Analysis/LoopAccessAnalysis.cpp
1112

What I meant was I did not see any codegen changes but in retrospect I added assertion and it hits almost all of SPEC200x, so this might impact compile time.

mcrosier added inline comments.Aug 30 2016, 9:21 AM
lib/Analysis/LoopAccessAnalysis.cpp
1112

Alternatively, you might be able to add a statistic (or two) to determine how often we actually hit this code.

bmakam added inline comments.Aug 30 2016, 11:23 AM
lib/Analysis/LoopAccessAnalysis.cpp
1112

6417 accesses were analyzed using computeKnownBits in Spec2kX with several benchmarks hitting between 500-1000 times.

bmakam abandoned this revision.Sep 1 2016, 8:07 AM

I am abandoning this patch because of the additional complexity involved for very minimal performance gain. Please feel free to revisit if you think otherwise.

I am abandoning this patch because of the additional complexity involved for very minimal performance gain. Please feel free to revisit if you think otherwise.

SGTM. Regardless, thanks for taking a look, Balaram.