<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div apple-content-edited="true"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "></div>
</div>
<br><div><div>On Mar 16, 2013, at 12:57 AM, Duncan Sands <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Hi Quentin,<br><br>On 15/03/13 23:14, Quentin Colombet wrote:<br><blockquote type="cite">Hi Anton, Hi Duncan,<br><br>We discussed offline with Bill on how we can improve the compile time of the<br>proposed patch.<br>What came out of this discussion is filtering out globals that are used in<br>inline asm or intrinsic is useless.<br></blockquote><br>I agree. In my experience most inline asm that uses a global G and wants it<br>as a label will just use "G" directly in the asm rather than taking G as an<br>input. Thus searching uses would never find it anyway. I think you should<br>simply not merge globals which are in the llvm.used array, as "G" should be<br>for such asm to be correct.<br><br>Therefore, we can focus on removing only the<br><blockquote type="cite">ones used in landing pad instruction (which is fast as the landing pad<br>instructions are terminator instructions).<br><br>What do you think?<br></blockquote><br>It makes sense to me.<br><br>Ciao, Duncan.<br><br><blockquote type="cite"><br>Thanks,<br><br>-Quentin<br><br>On Mar 15, 2013, at 1:46 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a><br><<a href="mailto:qcolombet@apple.com">mailto:qcolombet@apple.com</a>>> wrote:<br><br><blockquote type="cite">Bill,<br><br>Here are the numbers for SPEC.<br><br>I’ve measure 3 different configurations:<br>1. the compiler without the proposed patch (Reference)<br>2. the compiler with the proposed patch but global merge disabled on constants<br>(i.e., default behavior after the patch applied)<br>3. the compiler with the proposed patch and global merge enabled on constants<br>(i.e., with command line option global-merge-on-const).<br><br>I have attached 2 main comparisons: 1 vs 2 and 1 vs 3 (identify with<br>‘with_const’ for the latter).<br>This translates in 4 files because for each comparison I made a difference<br>between the tests with a compilation error I hit (“cannot find [some system<br>headers]”, these errors are the same between all the configurations) and the<br>tests without.<br><br>SPEC_failsXXX report numbers with the sysroot include error.<br>SPECXXX report numbers without any errors.<br><br>On average, the default behavior of the compiler does not impact the compile<br>time. When enabled, the constant processing has on average a negative impact<br>of 2%.<br><br>-Quentin<br><SPEC_fails-compile_time_with_const.txt><br><SPEC-compile_time_with_const.txt><br><SPEC_fails-compile_time.txt><br><SPEC-compile_time.txt><br><br>On Mar 15, 2013, at 11:33 AM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a><br><<a href="mailto:qcolombet@apple.com">mailto:qcolombet@apple.com</a>>> wrote:<br><br><blockquote type="cite">On Mar 15, 2013, at 10:49 AM, Bill Wendling <<a href="mailto:wendling@apple.com">wendling@apple.com</a><br><<a href="mailto:wendling@apple.com">mailto:wendling@apple.com</a>>> wrote:<br><br><blockquote type="cite">On Mar 15, 2013, at 9:51 AM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a><br><<a href="mailto:qcolombet@apple.com">mailto:qcolombet@apple.com</a>>> wrote:<br><br><blockquote type="cite">Hi Bill,<br><br>I’ve attached the measurement made on compile time for O3.<br>In that file, the Reference column is llvm r177120 without the proposed<br>patch and Test is the same compiler with the proposed patch and constant<br>merging enabled.<br>Both compilers have been generated without assertions and with<br>optimizations (i.e., release mode).<br><br>The speedup column reports a ratio: Test/Reference, thus the bigger the better.<br><br>On average, the impact is limited (0.99 speedup, thus 1% slow-down). The<br>maximum and minimum reported numbers are, in my opinion, not much relevant<br>as the related tests (SingleSource/UnitTests/Vector/build and<br>MultiSource/Benchmarks/MiBench/network-dijkstra/network-dijkstr) are<br>compiled very quickly and the measurement method is not that accurate.<br>Moreover, we have to keep in mind that this patch adds a check for a<br>currently bogus behavior with global variables maked as “used”.<br><br>Feel free to comment!<br><br></blockquote>Hrm. I was hoping that the results would be no change. The slowdowns are<br>small, but then so are the test cases. Would you be able to run some of the<br>SPEC tests to see if it shows up there?<br></blockquote>Yes, sure.<br><br><blockquote type="cite"><br>Sorry to ask you to do this. I know it's a pain. You may want to talk with<br>Nadav to see what he thinks. If he isn't concerned, then I will back off and<br>you can commit the new patch. :)<br></blockquote>Never mind, it’s just a command to run :).<br><br><blockquote type="cite"><br>-bw<br></blockquote><br>-Quentin<br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><span class="Apple-converted-space"> </span><<a href="mailto:llvm-commits@cs.uiuc.edu">mailto:llvm-commits@cs.uiuc.edu</a>><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br></blockquote><br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><span class="Apple-converted-space"> </span><<a href="mailto:llvm-commits@cs.uiuc.edu">mailto:llvm-commits@cs.uiuc.edu</a>><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></blockquote></blockquote></div></blockquote></div><br></div></body></html>