search for: 096488

...work on the predicate handling (actually, there's already a branch https://github.com/dberlin/llvm-gvn-rewrite/tree/newgvn-predicates). Please let us know what you think. Any feedback/review comment/testing is very appreciated! Thanks! [1] http://lists.llvm.org/pipermail/llvm-dev/2016-March/096488.html [2] https://llvm.org/bugs/show_bug.cgi?id=30692#c11 [3] http://dl.acm.org/citation.cfm?id=512536 -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare

...> https://github.com/dberlin/llvm-gvn-rewrite/tree/newgvn-predicates). > > > > Please let us know what you think. Any feedback/review comment/testing > > is very appreciated! > > > > Thanks! > > > > [1] http://lists.llvm.org/pipermail/llvm-dev/2016-March/096488.html > > [2] https://llvm.org/bugs/show_bug.cgi?id=30692#c11 > > [3] http://dl.acm.org/citation.cfm?id=512536 > > > > -- > > Davide > > > > "There are no solved problems; there are only problems that are more > > or less solved" -- Henri Poi...

LLVM has a wonderful policy regarding broken commits: we revert to green. We ask that a test case be available within a reasonable time frame (preferably before, but some exceptions can be made), but otherwise we revert the offending patch, even if it contains nice features that people want, and keep the tree green. This is an awesome policy. I would like to suggest we adopt and follow the same

Hi, TLDR: I totally support considering compile time regression as bug. I'm glad you bring this topic. Also it is worth pointing at this recent thread: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096488.html And also this blog post comparing the evolution of clang and gcc on this aspect: http://hubicka.blogspot.nl/2016/03/building-libreoffice-with-gcc-6-and-lto.html I will repeat myself here, since we also noticed internally that compile time was slowly degrading with time. Bruno and Chris are wo...