[llvm-dev] [GSoC 2016] Introduction - Polly as an Analysis pass in LLVM
Johannes Doerfert via llvm-dev
llvm-dev at lists.llvm.org
Sat May 7 16:43:31 PDT 2016
On 05/07, Mehdi Amini wrote:
>
> > On May 7, 2016, at 7:59 AM, Utpal Bora via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >
> > Dear All,
> >
> > I am glad to be part of GSoC 2016 with LLVM organization. I am a first year PhD student at IIT Hyderabad, India and my research area is compiler optimizations using polyhedral model.
> >
> > My GSoC 2016 project is to implement Polly as an Analysis pass in LLVM [1].
> > We have a discussion on Polly-dev mailing list [2] on taking a better approach to implement this project. Based upon this discussion, I am planning to cover the following items in the first month of this GSoC.
> >
> > 1: Decouple ScopInfo object from pass and create two passes. One region pass to preserve compatibility with existing Polly transformation passes, other will be a function pass to be used by PolyhedralInfo pass as mentioned below.
> >
> > 2: Decouple DependenceInfo object from pass and create two passes. Same as above.
> >
> > 3: Create the interface PolyhedralInfo, which will extract Memory Access wise dependence information from Polly and provide few simple interfaces like isParallel(), isVectorizable(), tripCount(Loop&).
>
> What is the difference between "isParallel" and "isVectorizable" for a loop?
> Also is tripCount() returning a literal or is it somehow symbolic?
In the beginning I would say isParallel() should return true if there
are no loop carried dependences, while isVectorizable(unsigned TripCount)
should return true if the loop carried dependencies are greater than
"TripCount".
Something like tripCount(Loop &L) can return either a constant or a
SCEV. I would prefer the latter.
Cheers,
Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160508/7351663f/attachment.sig>
More information about the llvm-dev
mailing list