[llvm-dev] [RFC] Polly Status and Integration

Hongbin Zheng via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 16 15:06:17 PDT 2017


On Sat, Oct 14, 2017 at 3:00 PM, Michael Kruse <llvmdev at meinersbur.de>
wrote:

> 2017-10-14 22:30 GMT+02:00 Hongbin Zheng <etherzhhb at gmail.com>:
> > I have a feeling that the LLVM LoopInfo/Loop datastructure, which only
> focus
> > on the CFG, is not sufficient.
> > And we build extra layer upon the LLVM LoopInfo/Loop, e.g. Scop in Polly
> and
> > the Hierarchical CFG in VPlan (right?).
> >
> > Maybe we can have layers between the existing LoopInfo/Loop and
> VPlan/SCoP:
> >
> > 1. LoopInfo/Loop
> > 2. LoopInfo/Loop + Hierarchical CFG
> > 3. LoopInfo/Loop + Hierarchical CFG + Memory Accesses description
> > 4. VPlan/Scop
> >
> > I think layer 2 and 3 will be very useful even outside of Polly and VPlan
>
> The idea is also that the new hierarchy can be modified iteratively
> and IR only generated at the end

In general 1-4 are different representations to the same program, or a set
of equivalent programs (at different levels of abstraction), and eventually
we need to properly connect different representations together such that we
can materialize the changes from one representation to another.
Maybe we could have a common infrastructure builtin to the Value class
hierarchy to allow us to easily connect LLVM IR to different
representations (e.g. SCoP or VPlan) and propagate the changes back?



> when all transform decisions have
> been made, and analysis/layers be shared between transformations, eg..
> a polyhedral dependency analysis, when available, can be used by the
> vectorizer without additional programming because the dependency data
> structure is the same

One way to achieve this is to design an interface like Alias Analsyis, to
hide different implementations behind a "common" interface.



> . PolyhedralInfo currently is very different from
> LoopAccessAnalysis.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171016/af31b51f/attachment.html>


More information about the llvm-dev mailing list