This is an archive of the discontinued LLVM Phabricator instance.

[LoopAccesses] Create the analysis pass
ClosedPublic

Authored by anemet on Feb 16 2015, 2:19 PM.

Details

Summary

This is a function pass that runs the analysis on demand. The analysis
can be initiated by querying the loop access info via LAA::getInfo. It
either returns the cached info or runs the analysis.

Symbolic stride information continues to reside outside of this analysis
pass. We may move it inside later but it's not a priority for me right
now. The idea is that Loop Distribution won't support run-time stride
checking at least initially.

This means that when querying the analysis, symbolic stride information
can be provided optionally. Whether stride information is used can
invalidate the cache entry and rerun the analysis. Note that if the
loop does not have any symbolic stride, the entry should be preserved
across Loop Distribution and LV.

Since currently the only user of the pass is LV, I just check that the
symbolic stride information didn't change when using a cached result.

On the LV side, LoopVectorizationLegality requests the info object
corresponding to the loop from the analysis pass. A large chunk of the
diff is due to LAI becoming a pointer from a reference.

A test will be added as part of the -analyze patch.

Also tested that with AVX, we generate identical assembly output for the
testsuite (including the external testsuite) before and after.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

Diff Detail

Event Timeline

anemet updated this revision to Diff 20053.Feb 16 2015, 2:19 PM
anemet retitled this revision from to [LoopAccesses] Create the analysis pass.
anemet updated this object.
anemet edited the test plan for this revision. (Show Details)
anemet added reviewers: hfinkel, aschwaighofer, nadav.
anemet added a subscriber: Unknown Object (MLST).
hfinkel added inline comments.Feb 16 2015, 4:38 PM
include/llvm/Analysis/LoopAccessAnalysis.h
200

We should be careful here; having an NDEBUG-dependent ABI is not necessarily desirable (and people complain about them). I believe there is currently a patch out for review to make our ABI non-NDEBUG-dependent. I'm not overly concerned about the size of this class (we won't have that many of them), so we may just want to always have this.

(may need to make it public, however, so that you don't get compiler warnings in -Asserts builds).

239

Returning a pointer seems odd here, who owns it? Should it be const?

lib/Analysis/LoopAccessAnalysis.cpp
1225

You can just grab DL, if available, from the Module. I think that's the "modern" way.

anemet added inline comments.Feb 16 2015, 4:50 PM
include/llvm/Analysis/LoopAccessAnalysis.h
239

It's owned by the pass using a unique_ptr. There is no transfer of ownership in getInfo. It simply gives out a pointer with unique_ptr::get(). I can extend the comment to explain the ownership situation.

Regarding const, absolutely but right now these interfaces don't use const so the pointer returned won't have access to most things. Would it be OK to fix this in a follow-up patch?

hfinkel added inline comments.Feb 16 2015, 4:53 PM
include/llvm/Analysis/LoopAccessAnalysis.h
239

Why not return a reference?

Fixing const in follow-up is okay.

anemet added inline comments.Feb 16 2015, 4:59 PM
include/llvm/Analysis/LoopAccessAnalysis.h
239

Makes sense. I am still bit confused when to use pointers vs. reference in LLVM...

Thanks.

anemet updated this revision to Diff 20104.Feb 17 2015, 12:36 PM

Address Hal's comments:

  • analyzeLoop is now called from the constructor
  • Fix NDEBUG for NumSymbolicStrides
  • Reference is returned from LAA::getInfo
  • DL accessed from the module
hfinkel accepted this revision.Feb 17 2015, 7:26 PM
hfinkel edited edge metadata.

LGTM (please fix the const-correctness in follow-up).

This revision is now accepted and ready to land.Feb 17 2015, 7:26 PM

LGTM (please fix the const-correctness in follow-up).

The cost-correctness fix is r229634.

anemet closed this revision.Mar 1 2015, 9:36 PM

r229893