[llvm-dev] Inclusion of Polly and isl into core LLVM

[Chris Lattner via llvm-dev]

> On Jan 15, 2018, at 1:44 PM, Tobias Grosser via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Short summary:
> 
> * Today Polly is already part of each LLVM release (and will be shipping with LLVM 6.0) for everybody to try, with conservative defaults.
> * We proposed to include Polly and isl into LLVM to provide modern high-level loop optimizations into LLVM
> * We suggested to develop Polly and isl as part of core LLVM to make interactions with the core LLVM community easier and to allow us to better integrate Polly with the new pass manager.

I’m definitely in favor of moving polly to a more normal structure as an LLVM subproject.

If I understand correctly, you are proposing several different things:
1) Moving the polly mailing lists to more conventional structured llvm mailing lists.
2) Putting a copy of ISL into LLVM.
3) Moving Polly out of its own subproject into the main llvm repo.
4) Turning on polly by default.

Here is my opinion about these steps:

1) This would be great IMO, I’m not sure why Polly was on google groups in the first place.  That said, I don’t see a strong advantage to having polly discussion on llvm-dev, rather than just move polly-dev to the llvm list-serv.

2) This is complicated and unconventional for several reasons, but we can lead that to the other thread.  It also doesn’t seem required by the other goals you have.

3) I do not understand the motivation of this at all.  Polly in its own subproject seems perfectly logical to me, just like clang is in its own subproject.  In the context of the git migration, we’re talking about going to an uber tree.  In that scenario, I can see how integrating polly makes sense, but in the absence of that, I don’t understand the motivation.  The LLVM svn repo is already too monolithic in the SVN design, making it larger isn’t a feature.

4) I know this isn’t a strong goal immediately, but it has to be a goal to justify the other steps.  I’d like to know more about this: what is the path towards this, what are the thresholds and criteria that you think make sense, how likely are those to happen, and why should we move polly into the tree before these criteria are established and met?


> Let me briefly summarize the LLVM developer meeting comments on our proposal (subjective summary)
> 
> * Most people were interested in having polyhedral loop optimizations being part of LLVM.

Right, but Polly is already part of LLVM.

What is your pitch for why Polly’s status should change?  Why is it good for the LLVM project?  What code benefits from it?  If you want it integrated as part of (e.g.) Clang builds, why does it need to move into the LLVM repo?  What is your path to getting it on by default?  What codes (out side of already-known-hackable SPEC benchmarks and BLAS kernels) does polly benefit?

Here is another way of asking the question: Clang is the default compiler for several large OS’s, including (e.g.) FreeBSD.  What programs does Polly show a measurable benefit for?

-Chris