[LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged

[Jack Howarth]

On Wed, Feb 18, 2015 at 4:46 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Wed, Feb 18, 2015 at 03:59:15PM -0500, Tom Honermann wrote:
>> On 02/18/2015 03:01 PM, Renato Golin wrote:
>> >So it seems that you're one of the very few people that doesn't use
>> >ToT. Almost everyone else uses it and the progress of LLVM kind of
>> >assume you do.
>>
>> My company also does not use ToT.  Being able to associate a product
>> with a well-known release is *very* important to us.  It enables
>> communication with our customers.  It allows us to determine
>> compatibility between our Clang derived product and other Clang
>> derived products.  It allows us to easily discuss groups of feature
>> sets.
>>
>> I personally find it rather crazy that developers are expected to
>> use ToT (and then determine stability on their own).  Why have an RC
>> series at all if that is the case?
>
> Let's go back a step. This started because a performance regression was
> reported very late in the release cycle of 3.6. A performance regression
> by 20% or 40% is annoying for whoever is affected by it, but it is not a
> critical issue like miscompilation. From the current state of the
> analysis, it is not even clear *why* it happens. There are various
> patterns like very hot inner loops where minimal changes to the
> resulting code can have huge impact on the performance, without being
> able to tell from looking at it why that is the case. The combination
> results in a sane decision for release management to not consider this a
> blocker. It doesn't mean people are ignoring it (now that it has
> actually been reported in the proper place, not somewhere on the
> internete (TM)). For me, the most critical job of a compiler is creating
> working output. The second most critical job is to not pointlessly
> create horrible code when the input was "simple enough". Everything else
> is nice to have.

Are you sure that is true? My understanding is that the regression caused
by  r222453 and the necessary fix is in fact well understood.

http://llvm.org/bugs/show_bug.cgi?id=22589#c26
http://llvm.org/bugs/show_bug.cgi?id=22589#c33
http://llvm.org/bugs/show_bug.cgi?id=22589#c36
http://llvm.org/bugs/show_bug.cgi?id=22589#c43
http://llvm.org/bugs/show_bug.cgi?id=22589#c54
http://reviews.llvm.org/D7715

Now I agree that the other 50% of the performance regression due to
r217953 is not understood yet...

http://llvm.org/bugs/show_bug.cgi?id=22589#c27

but that is an entirely orthogonal issue that just happens to hit the
same benchmark.
           Jack

>
> Now Renato's comment about many developers focusing on ToT is a direct
> result of the development pace of LLVM. It is not appropiate for
> everyone. If your product is mostly about clang as parser for example,
> code changes are not nearly as important to trace in real time. The APIs
> tend to be quite a bit more stable and the number of fixes and new
> features is also lower. A release is also a good point in time to focus
> on stabilizing things and shacking out bugs. It doesn't mean that's
> ignored the rest of the time, but development focus certainly does
> shift for a while around releases. That's something the github model of
> "just pull whatever is in trunk" ignores.
>
> Finally, the LLVM community has been starting to put more effort into
> release maintainance. A release two years ago was essentially a
> hit-and-miss effort. With 3.4 and to a much greater degree 3.5, the
> release branch gets further bug fixes and point releases are done.
> Kudos to the release manager for that, you know who you are.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev