<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 6:15 PM, Johannes Doerfert via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually, I started to copy parts of the ScalarEvolution interface in<br>
order to integrate the analysis passes this way into LLVM<br>
transformations. While it is obviously hard (and probably not useful) to<br>
provide "exactly" the same interface as ScalarEvolution, I can look at<br>
the use cases e.g., LoopDeletion, and try to come up with a general way<br>
to convey the needed information, e.g. "bool mayBeInfinite(Loop *L)".<br>
<br>
My point is that I can easily use the modular analysis design to do only<br>
what is needed to answer a query without any worrying about side effects<br>
that are of no concern.</blockquote><div><br></div><div>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).</div><div><br></div><div>I am okay with having those two approaches in LLVM itself.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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?).</div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</div></div>