On 12-02-09 5:54 PM, Tobias Grosser wrote:
On 02/09/2012 11:37 PM, Tobias Grosser wrote:
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work? Unfortunately Sebastian switched jobs at the end of 2011, such
that we lost one full time contributor. Furthermore, I am myself also
not full time working on Graphite, but work on my PhD where I am
founded to work on the LLVM Polly project. This means developer
resources are currently rare.
To solve this issue, I believe the best approach is to share as much
infrastructure as possible between different projects.
I just thought about licensing. If you are going to share the code
between GCC and LLVM, who will be the owner (FSF or UIUC). But may be I
understood you incorrectly and you meant only libraries (isl etc).
Both. Libraries are simple, as they are just used. For code I can only
share code that I have written. That means, if I have written code I can
add it at both places. If people start to contribute, moving code
becomes more difficult. However, I assume that most of the stuff that
can be shared will actually be part of isl, and only compiler specific
stuff goes into GCC and LLVM. So I do not expect that a lot of code
needs to be moved later on.
Or maybe I should be more specific.
I think the stuff that can actually be shared are polyhedral concepts
and algorithms. Those are mathematical algorithms which are so high
level that they are compiler independent. For Graphite and Polly
itself I do not see too much code reuse. Obviously they will share
some techniques and ideas, but the actual implementation will strongly
depend on the compiler it is built for. Here we have not only
different coding styles and conventions, but also different needs how
we interact with the rest of the compilers, which heuristics we choose
and how in general we use the polyhedral techniques. I have earlier
implemented some algorithms for both compiler, but as soon as they are
pushed upstream they slowly start to diverge and to adapt to what is
best for each compiler. From that on I believe the sharing will most
probably happen by sharing experience and ideas, not actual code. Not
having the same code base will also allow both projects to explore new
directions individually, which may result in useful ideas for both.
Personally, I'd prefer that you focus more on GCC but it probably does
not depend only from you. I think the final results for LLVM will look
better than for GCC because LLVM generated code not so optimized as GCC one.
Thanks for the clarification, Tobias. In general, it looks ok for me
although there are always some advantages and disadvantages of such
approach: better resource usage but less competition as the approach to
loop optimizations in the both compilers will be basically the same.
