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

[Alexandre Isoard via llvm-dev]

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.

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170928/7cb3b4e9/attachment.html>