[PATCH] [LoopVectorize] Move LoopAccessAnalysis to its own module
hfinkel at anl.gov
Sat Jan 31 05:21:57 PST 2015
----- Original Message -----
> From: "Adam Nemet" <anemet at apple.com>
> To: anemet at apple.com, aschwaighofer at apple.com, hfinkel at anl.gov
> Cc: llvm-commits at 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
> 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
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.
> EMAIL PREFERENCES
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits