This is an archive of the discontinued LLVM Phabricator instance.

[LoopVectorize] Move LoopAccessAnalysis to its own module
ClosedPublic

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

Details

Summary

Other than moving code and adding the boilerplate for the new files, the code
being moved is unchanged.

There are a few global functions that are shared with the rest of the
LoopVectorizer. I moved these to the new module as well (emitLoopAnalysis,
stripIntegerCast, replaceSymbolicStrideSCEV) along with the Report class used
by emitLoopAnalysis. There is probably room for further improvement in this
area.

I kept DEBUG_TYPE "loop-vectorize" because it's used as the PassName with
emitOptimizationRemarkAnalysis. This will obviously have to change.

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 19014.Jan 29 2015, 4:53 PM
anemet retitled this revision from to [LoopVectorize] Move LoopAccessAnalysis to its own module.
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:07 AM
include/llvm/Analysis/LoopAccessAnalysis.h
38

Should this really be a public class? It lacks a proper interface, and the meaning of the dependency set ids is not really defined.

anemet added inline comments.Jan 30 2015, 10:31 AM
include/llvm/Analysis/LoopAccessAnalysis.h
38

My hope is that in the long run this becomes private to LAA. The problem right now is that the actual code emission happens in InnerLoopVectorizer::addRuntimeCheck which uses an instance of this class.

My plan is to move addRuntimeCheck to LAA as well of course and I see no reason why this would have to remain public after that.

I can move this class inside LAA. It would of course still be public but at least it would tie it better to LAA in the interim. What do you think?

hfinkel edited edge metadata.Jan 30 2015, 10:33 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:31:44 PM
Subject: Re: [PATCH] [LoopVectorize] Move LoopAccessAnalysis to its own module

Comment at: include/llvm/Analysis/LoopAccessAnalysis.h:37
@@ +36,3 @@
+/// check that a group of pointers do not overlap.
+struct RuntimePointerCheck {

+ RuntimePointerCheck() : Need(false) {}

hfinkel wrote:

Should this really be a public class? It lacks a proper interface,
and the meaning of the dependency set ids is not really defined.

My hope is that in the long run this becomes private to LAA. The
problem right now is that the actual code emission happens in
InnerLoopVectorizer::addRuntimeCheck which uses an instance of this
class.

My plan is to move addRuntimeCheck to LAA as well of course and I see
no reason why this would have to remain public after that.

I can move this class inside LAA. It would of course still be public
but at least it would tie it better to LAA in the interim. What do
you think?

I think that would be better.

-Hal

http://reviews.llvm.org/D7285

EMAIL PREFERENCES

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

Has the missing LAA member functions noticed by Hal. Rebased and refreshed
with the rest of the patchset.

hfinkel added inline comments.Jan 31 2015, 12:10 AM
include/llvm/Analysis/LoopAccessAnalysis.h
38

Please rename this -- VectorizationReport perhaps?

184

These functions are really private to the two implementations; having them in the top-level llvm namespace seems somewhat unfortunate. Any thoughts on some better placement?

192

We should better document what this does, that PtrToStride is, etc.

anemet added inline comments.Jan 31 2015, 12:47 AM
include/llvm/Analysis/LoopAccessAnalysis.h
184

One option would be to make it a static member function VectorizationReport.

192

Sure. I'll do that. (We may want to further clean this up later and move the symbolic stride logic to LAA as well.)

Should I also make stripIntegerCast a member function of Value? Or is it OK to do that later?

  • Original Message -----

From: "Adam Nemet" <anemet@apple.com>
To: anemet@apple.com, aschwaighofer@apple.com, hfinkel@anl.gov
Cc: llvm-commits@cs.uiuc.edu
Sent: Saturday, January 31, 2015 2:48:01 AM
Subject: Re: [PATCH] [LoopVectorize] Move LoopAccessAnalysis to its own module

Comment at: include/llvm/Analysis/LoopAccessAnalysis.h:183
@@ +182,3 @@
+/// \p Message or \p TheLoop's.
+void emitLoopAnalysis(Report &Message, const Function *F, const Loop
*L);

+

hfinkel wrote:

These functions are really private to the two implementations;
having them in the top-level llvm namespace seems somewhat
unfortunate. Any thoughts on some better placement?

One option would be to make it a static member function
VectorizationReport.

I like that better.

Comment at: include/llvm/Analysis/LoopAccessAnalysis.h:191
@@ +190,3 @@
+/// \p Ptr.
+const SCEV *replaceSymbolicStrideSCEV(ScalarEvolution *SE,

+ ValueToValueMap &PtrToStride,

hfinkel wrote:

We should better document what this does, that PtrToStride is, etc.

Sure. I'll do that. (We may want to further clean this up later and
move the symbolic stride logic to LAA as well.)

Should I also make stripIntegerCast a member function of Value? Or
is it OK to do that later?

Let's do that later. For one thing, the stripPointerCasts* functions in Value are recursive, but this function is not. Also, stripIntegerCast is only used in two places within the vectorizer implementation. It is not immediately clear to me why it is written as it is (is it really there to deal with inttoptr casts?). I'm not sure that it has enough obvious utility to bring it into Value.

Thanks again,
Hal

http://reviews.llvm.org/D7285

EMAIL PREFERENCES

http://reviews.llvm.org/settings/panel/emailpreferences/
anemet added inline comments.Jan 31 2015, 4:00 PM
include/llvm/Analysis/LoopAccessAnalysis.h
38

Please see the new review D7317.

184

See the update to D7280.

192

Next rev will have this.

anemet updated this revision to Diff 19103.Jan 31 2015, 4:11 PM

Refresh with the patchset. Improve the comment for replaceSymbolicStrideSCEV.

hfinkel accepted this revision.Jan 31 2015, 6:39 PM
hfinkel edited edge metadata.

I'm assuming the idea is to turn this into a proper analysis pass, but this is a good intermediate step. LGTM.

This revision is now accepted and ready to land.Jan 31 2015, 6:39 PM

I'm assuming the idea is to turn this into a proper analysis pass, but this is a good intermediate step. LGTM.

Yes, this was the first step of pure refactoring. Thanks.

anemet closed this revision.Feb 2 2015, 11:49 AM

r227756