This is an archive of the discontinued LLVM Phabricator instance.

[LoopVectorize] Split out LoopAccessAnalysis from LoopVectorizationLegality
ClosedPublic

Authored by anemet on Jan 29 2015, 4:53 PM.

Details

Summary

Move the canVectorizeMemory functionality from LoopVectorizationLegality to a
new class LoopAccessAnalysis and forward users.

Currently the collection of the symbolic stride information is kept with
LoopVectorizationLegality and it becomes an input to LoopAccessAnalysis.

NFC. This is part of the patchset that splits out the memory dependence logic
from LoopVectorizationLegality into a new class LoopAccessAnalysis.
LoopAccessAnalysis will be used by the new Loop Distribution pass.

Diff Detail

Event Timeline

anemet updated this revision to Diff 19011.Jan 29 2015, 4:53 PM
anemet retitled this revision from to [LoopVectorize] Split out LoopAccessAnalysis from LoopVectorizationLegality.
anemet updated this object.
anemet edited the test plan for this revision. (Show Details)
anemet added reviewers: hfinkel, aschwaighofer.
anemet added a subscriber: Unknown Object (MLST).
hfinkel added inline comments.Jan 30 2015, 5:06 AM
lib/Transforms/Vectorize/LoopVectorize.cpp
674

This class does not do anything "at run-time" ;)

1852

Can you please group together the implementations of the functions for each class? I can see some advantage to having these two near each other, but in the end, I think having the implementation spread out over different parts of the file is confusing.

5073

(here too, please group these with the others)

anemet added inline comments.Jan 30 2015, 10:15 AM
lib/Transforms/Vectorize/LoopVectorize.cpp
674

Sure, I'll reword it.

1852

Sure. I just kept the original order so that it's immediately apparent what changed in the diff. Sometime these things show up as code movement with modifications which are harder to figure out.

What do you think about adjusting the order in an additional step in the patchset?

hfinkel edited edge metadata.Jan 30 2015, 10:24 AM
  • Original Message -----

From: "Adam Nemet" <anemet@apple.com>
To: anemet@apple.com, hfinkel@anl.gov, aschwaighofer@apple.com
Cc: llvm-commits@cs.uiuc.edu
Sent: Friday, January 30, 2015 12:16:00 PM
Subject: Re: [PATCH] [LoopVectorize] Split out LoopAccessAnalysis from LoopVectorizationLegality

Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:613
@@ +612,3 @@
+/ This class is responsible for analyzing the memory accesses of a
loop either
+
/ at compile or at run-time. It collects the accesses and then
its main
+/// helper the AccessAnalysis class finds and categorizes the

dependences in

hfinkel wrote:

This class does not do anything "at run-time" ;)

Sure, I'll reword it.

Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:1800
@@ -1744,3 +1799,3 @@

-bool LoopVectorizationLegality::isUniform(Value *V) {
+bool LoopAccessAnalysis::isUniform(Value *V) {

return (SE->isLoopInvariant(SE->getSCEV(V), TheLoop));

hfinkel wrote:

Can you please group together the implementations of the functions
for each class? I can see some advantage to having these two near
each other, but in the end, I think having the implementation
spread out over different parts of the file is confusing.

Sure. I just kept the original order so that it's immediately
apparent what changed in the diff. Sometime these things show up as
code movement with modifications which are harder to figure out.

What do you think about adjusting the order in an additional step in
the patchset?

Sure. Just make sure you get them all when you move them into the new file (I think some of these out-of-order ones may have been missed in the later patchset).

-Hal

http://reviews.llvm.org/D7282

EMAIL PREFERENCES

http://reviews.llvm.org/settings/panel/emailpreferences/
anemet updated this revision to Diff 19081.Jan 30 2015, 11:34 PM
anemet edited edge metadata.

Rebased and fixed the silly comment noticed by Hal

hfinkel accepted this revision.Jan 30 2015, 11:43 PM
hfinkel edited edge metadata.

Given that you'll be moving the aforementioned functions that are not grouped with the others to a different file anyway, LGTM.

This revision is now accepted and ready to land.Jan 30 2015, 11:43 PM
anemet closed this revision.Feb 2 2015, 11:58 AM

r227751