search for: d12826

...Apparently in the past (years/decade ago?) the project was very conservative on adding any optimizations that would impact compile time, however there is no explicit policy (that I know of) to address this tradeoff. The closest I could find would be what Chandler wrote in: http://reviews.llvm.org/D12826 <http://reviews.llvm.org/D12826> ; for instance for O2 he stated that "if an optimization increases compile time by 5% or increases code size by 5% for a particular benchmark, that benchmark should also be one which sees a 5% runtime improvement". My hope is that with better toolin...

...tally support considering compile time regression as bug. Me too. I also agree that reverting fresh and reapplying is *much* easier than trying to revert late. But I'd like to avoid dubious metrics. > The closest I could find would be what Chandler wrote in: > http://reviews.llvm.org/D12826 ; for instance for O2 he stated that "if an > optimization increases compile time by 5% or increases code size by 5% for a > particular benchmark, that benchmark should also be one which sees a 5% > runtime improvement". I think this is a bit limited and can lead to which hunts,...

...(years/decade > ago?) the project was very conservative on adding any optimizations > that would impact compile time, however there is no explicit policy > (that I know of) to address this tradeoff. > The closest I could find would be what Chandler wrote in: > http://reviews.llvm.org/D12826 ; for instance for O2 he stated that > "if an optimization increases compile time by 5% or increases code > size by 5% for a particular benchmark, that benchmark should also be > one which sees a 5% runtime improvement". > > My hope is that with better tooling for tracking...

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

I have just benchmarked building trunk llvm and clang in Debug, Release and LTO modes (see the attached scrip for the cmake lines). The compilers used were clang 3.5, 3.6, 3.7, 3.8 and trunk. In all cases I used the system libgcc and libstdc++. For release builds there is a monotonic increase in each version. From 163 minutes with 3.5 to 212 minutes with trunk. For comparison, gcc 5.3.2 takes

...uot; is a dubious metric. The metric is not dubious IMO, it is what it is: a measurement. You just have to cast a good process around it to exploit this measurement in a useful way for the project. >> The closest I could find would be what Chandler wrote in: >> http://reviews.llvm.org/D12826 ; for instance for O2 he stated that "if an >> optimization increases compile time by 5% or increases code size by 5% for a >> particular benchmark, that benchmark should also be one which sees a 5% >> runtime improvement". > > I think this is a bit limited and ca...