[llvm-dev] [RFC] Polly Status and Integration
Johannes Doerfert via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 29 03:05:00 PDT 2017
great to get more people involved! (That also includes Sebastian who
wrote the last mail).
On 09/28, Alexandre Isoard wrote:
> On Thu, Sep 28, 2017 at 6:15 PM, Johannes Doerfert via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > Actually, I started to copy parts of the ScalarEvolution interface in
> > order to integrate the analysis passes this way into LLVM
> > transformations. While it is obviously hard (and probably not useful) to
> > provide "exactly" the same interface as ScalarEvolution, I can look at
> > the use cases e.g., LoopDeletion, and try to come up with a general way
> > to convey the needed information, e.g. "bool mayBeInfinite(Loop *L)".
> > My point is that I can easily use the modular analysis design to do only
> > what is needed to answer a query without any worrying about side effects
> > that are of no concern.
> Great! We do some wonderful stuff with ScalarEvolution and I was waiting
> for something like that to exploit some of that polyhedral magic. I think
> that this is a promising approach. However, because having Polyhedral
> Analysis is an orthogonal approach to Polly (which is more like a
> Polyhedral IR), it is not really correlated with the true goal of this
> discussion: integrating Polly or not into LLVM (except that it would mean
> isl is already a dependency).
> I am okay with having those two approaches in LLVM itself.
I do not object to this statement, nor to the reasoning below. I
mentioned before that Polly is the (only) way to get a full blown
polyhedral compiler pipeline, at least for the foreseeable future. My
main arguments targeted the use of parts of it as stand-alone analyses
and you summarized that well.
> Polly is oriented towards providing a full blown polyhedral compiler
> pipeline, this is great in the sense that it allows to do all the high
> level transformations we can dream of, but this is also difficult to
> compose with current LLVM passes, we lose debug information, and it is
> relatively hard to control what happen. As such, it might be fine in its
> own folder, I don't see much interest in "not compiling Polly" except if to
> not have the isl library as a dependency.
> Polyhedral Analysis is oriented towards providing new tools for any LLVM
> analysis or transformation passes. There is a wide range of applicability
> to this (it can at least be used almost everywhere ScalarEvolution can),
> and because it can represent set and relations (instead of only functions
> like SCEV) I suspect it can be used in an even wider range of applications
> and a lot of them are outside the polyhedral realm (aka. will hardly ever
> fit into Polly's pipeline).
> As for the isl as a dependency, I don't really mind. isl is a relatively
> small library with a rather stable interface, and its compilation time is
> quite short. Including the whole source code (like Polly), or requesting it
> as an external dependency is probably fine. I would suggest however that we
> don't diverge from upstream isl if we continue the route of including the
> source code (we might want to upstream a CMake build?).
> *Alexandre Isoard*
Researcher / PhD Student
Compiler Design Lab (Prof. Hack)
Saarland Informatics Campus, Germany
Building E1.3, Room 4.31
Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065 : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: Digital signature
More information about the llvm-dev