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

[Johannes Doerfert via llvm-dev]

Hi Alexandre,

great to get more people involved! (That also includes Sebastian who
wrote the last mail).

On 09/28, Alexandre Isoard wrote:
> Hi,
> 
> 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.

Thanks!

--
  Johannes

> 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*

-- 

Johannes Doerfert
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...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170929/a4f7fe7d/attachment.sig>