[llvm-dev] llvm is getting slower, January edition

Thu Jan 19 16:24:05 PST 2017

> On Jan 19, 2017, at 4:23 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
> Both clang-3.9.1 and clang-4.0.0 were built with the same compiler and the same options (ThinLTO Release build, without PGO).

(Same compiler being clang-4.0, itself bootstrapped with ThinLTO)


> 
>> On Jan 19, 2017, at 4:22 PM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote:
>> 
>> Ah but how did you compile the clang-4.0 you were using? Does it run faster if you compile it with clang-4.0? :)
>> 
>> On Fri, Jan 20, 2017 at 4:09 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> Hi,
>> 
>> On this topic, I just tried to build ToT with clang-3.9.1 and clang-4.0 and the total time to complete `ninja clang` on this machine went from 12m54s to 13m44s for RelWithDebInfo (6.5% slower!) and 11m18s to 12m06s for Release (7% slower!).
>> 
>> —
>> Mehdi
>> 
>> > On Jan 17, 2017, at 6:02 PM, Mikhail Zolotukhin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> >
>> > Hi,
>> >
>> > Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.
>> >
>> > Configuration:
>> > The test I used is tramp3d-v4 from LLVM testsuite. It consists of a single source file, but still takes a noticeable time to compile, which makes it very convenient for this kind of experiments. The file was compiled with Os for arm64 on x86 host.
>> >
>> > Results:
>> > The attached PDF has a compile time graph, on which I marked points where compile time changed with a list of corresponding commits. A textual version of the list is available below, but I think it might be much harder to comprehend the data without the graph. A number in the end shows compile time change after the given commit:
>> >
>> > 1. r239821: [InstSimplify] Allow folding of fdiv X, X with just NaNs ignored. +1%
>> > 2. r241886: [InstCombine] Employ AliasAnalysis in FindAvailableLoadedValue. +1%
>> > 3. r245118: [SCEV] Apply NSW and NUW flags via poison value analysis for sub, mul and shl. +2%
>> > 4. r246694: [RemoveDuplicatePHINodes] Start over after removing a PHI. -1%
>> > 5. r247269: [ADT] Rewrite the StringRef::find implementation to be simpler... +1%
>> >   r247240: [LPM] Use a map from analysis ID to immutable passes in the legacy pass manager... +3%
>> >   r247264: Enable GlobalsAA by default. +1%
>> > 6. r247674: [GlobalsAA] Disable globals-aa by default. -1%
>> > 7. r248638: [SCEV] Reapply 'Teach isLoopBackedgeGuardedByCond to exploit trip counts'. +2%
>> > 8. r249802: [SCEV] Call `StrengthenNoWrapFlags` after `GroupByComplexity`; NFCI. +4%
>> > 9. r250157: [GlobalsAA] Turn GlobalsAA on again by default. +1%
>> > 10. r251049: [SCEV] Mark AddExprs as nsw or nuw if legal. +23%
>> > 11. No data
>> > 12. r259252: AttributeSetImpl: Summarize existing function attributes in a bitset. -1%
>> >    r259256: Add LoopSimplifyCFG pass. -2%
>> > 13. r262250: Enable LoopLoadElimination by default. +3%
>> > 14. r262839: Revert "Enable LoopLoadElimination by default". -3%
>> > 15. r263393: Remove PreserveNames template parameter from IRBuilder. -3%
>> > 16. r263595: Turn LoopLoadElimination on again. +3%
>> > 17. r267672: [LoopDist] Add llvm.loop.distribute.enable loop metadata. +4%
>> > 18. r268509: Do not disable completely loop unroll when optimizing for size. -34%
>> > 19. r269124: Loop unroller: set thresholds for optsize and minsize functions to zero. +50%
>> > 20. r269392: [LoopDist] Only run LAA for loops with the pragma. -4%
>> > 21. r270630: Re-enable "[LoopUnroll] Enable advanced unrolling analysis by default" one more time. -28%
>> > 22. r270881: Don't allocate in APInt::slt.  NFC. -2%
>> >    r270959: Don't allocate unnecessarily in APInt::operator[+-].  NFC. -1%
>> >    r271020: Don't generate unnecessary signed ConstantRange during multiply.  NFC. -3%
>> > 23. r271615: [LoopUnroll] Set correct thresholds for new recently enabled unrolling heuristic. +22%
>> > 24. r276942: Don't invoke getName() from Function::isIntrinsic(). -1%
>> >    r277087: Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942. +1%
>> > 25. r279585: [LoopUnroll] By default disable unrolling when optimizing for size.
>> > 26. r286814: [InlineCost] Remove skew when calculating call costs. +3%
>> > 27. r289755: Make processing @llvm.assume more efficient by using operand bundles. +6%
>> > 28. r290086: Revert @llvm.assume with operator bundles (r289755-r289757). -6%
>> > <CompileTime.pdf>
>> > Disclaimer:
>> > The data is specific for this particular test, so I could have skipped some commits affecting compile time on other workloads/configurations.
>> > The data I have is not perfect, so I could have skipped some commits, even if they impacted compile-time on this test case.
>> > Same commits might have a different impact on a different test/configuration, up to the opposite to the one listed.
>> > I didn't mean to label any commits as 'good' or 'bad' by posting these numbers. It's expected that some commits increase compile time, we just need to be aware of it and avoid unnecessary slowdowns.
>> >
>> > Conclusions:
>> > Changes in optimization thresholds/cost-models usually have the biggest impact on compile time. However, usually they are well-assessed and trade-offs are discussed and agreed on.
>> > Introducing a pass doesn't necessarily mean a compile time slowdown. Sometimes the total compile time might decrease because we're saving some work for later passes.
>> > There are many commits, which individually have a low compile time impact, but together sum up to a noticeable slowdown.
>> > Conscious efforts on reducing compile time definitely help - thanks everyone who's been working on this!
>> >
>> > Thanks for reading, any comments or suggestions on how to make LLVM faster are welcome! I hope we'll see this graph going down this year :-)
>> >
>> > Michael
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20170119/b2eb76f7/attachment.html>