Graphite news

[Tobias Grosser]

On 02/10/2012 01:58 AM, Vladimir Makarov wrote:
> 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.

Hey Vladimir,

thanks for your feedback!

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

No, not entirely. There have been various reasons to start with 
Polly/LLVM, one the need for GPU code generation. Even though I now need 
to split my development time, I am  still very interested in continuing 
the development of Graphite.

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

It really depends who steps in to do the work. I will for myself 
obviously not take two entirely different approaches for GCC and LLVM, 
but I welcome everybody to join the loop optimization affords. If people 
want to take different ways I am the last person to block anybody. 
Please complain loudly, if any of the directions I propose for Graphite 
does not sound right to you. You are invited to either convince me to 
change directions or to experiment with a different approach. I am eager 
to learn where I fail badly or where I could do better.

In terms of competition I agree and I also see both positive and 
negative points. One good point I see is that with the joint polyhedral 
base library the competition now moves to the kind of high level 
optimizations implemented, instead of competing over the quality of the 
low level infrastructure.

Cheers
Tobi