[llvm-dev] llvm (the middle-end) is getting slower, December edition

[Gerolf Hoflehner via llvm-dev]

For work like this you should look for leveraging the CTMark compile-time tracking http://lab.llvm.org:8080/green/view/Compile%20Time/ <http://lab.llvm.org:8080/green/view/Compile%20Time/> . While the focus there is on O0g and Os, O3 LTO is tracked too. Your numbers should be similar to what could be measured for one or more benchmarks in that suite. In that case there is either work in progress to recover the regression or at least there is a chance the reason/commit is known. On the other hand, if your test case exposes a regression not caught by the suite, it might be a good candidate to add (or replace an existing test of) to CTMark.

-Gerolf





> On Dec 18, 2016, at 11:45 AM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Sun, Dec 18, 2016 at 11:10 AM, Philip Reames
> <listmail at philipreames.com> wrote:
>> On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev wrote:
>>> 
> [...]
>> 
>> I'd really like to see a profile which broke down the time spent in Value
>> Propagation and LVI.  As the person who has touched both most recently, I am
>> probably the responsible party.  At the same time, there are a number of
>> known fixes we can apply depending on the way this particular compile time
>> problem exhibits.  I'm happy to take a look at this particular issue if you
>> can given me enough information to analyze it.
>> 
> 
> I'll try to reduce the testcase and do some profiling on it, then come
> back to you.
> Something to keep in mind, please note I'm not pointing fingers. The
> main motivation behind this e-mail is showing up that multiple passes
> in the compiler seem to have regressed on large testcases. Many people
> don't notice because they are (un)lucky enough to not run with LTO.
> There are probably/maybe other regressions uncovered by my
> non-exahustive analysis. I wasn't particularly pleased after a fair
> amount of time working on GVN to clean up technical-debt to realize
> that the compiler got slower in other areas.
This is why we installed regular tracking. Otherwise there is no way to avoid (or at least be on top of it) such “surprises”. And after their discovery more often than not efforts like yours either evaporated in the cloud of best intentions or were offset by regular developments.
> 
> -- 
> Davide
> 
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161220/c9426dfa/attachment.html>