<div dir="ltr">Interesting.<div>Do you have a profile of tramp3d-v4 before and after.</div><div>This should hopefully just be something stupid we can fix<br><div><br></div></div><div>(This is one reason i hate lazy analysis - it's really complex, and often not really lazy, and then ends up with weird hacks and limits to make it work in sane time limits.</div><div>You would have zero of these problems, and probably get better results, with a non-lazy LVI computed once or at worst incrementally recomputed each iteration during JT)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 9, 2018 at 9:10 AM, Brian Rzycki via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">brzycki added a comment.<br>
<br>
@dberlin thank you for the suggestion and I have implemented the change. The good news is `sqlite` is back to our original performance. The not-so-great news is this causes a regression for `tramp3d-v4`:<br>
<br>
brzycki@cc01 /work/brzycki/test-suite $ ~/git/me/llvm/litdiff build.upstream/results.json build.D42717_newpatch/results.<wbr>json compile_time<br>
# left column: build.upstream/results.json<br>
# right column: build.D42717_newpatch/results.<wbr>json<br>
# metric name: compile_time<br>
493.8600 <- 536.3320 [ 8.60%] CTMark/tramp3d-v4/tramp3d-v4.<wbr>test<br>
336.3600 <- 343.2440 [ 2.05%] CTMark/sqlite3/sqlite3.test<br>
373.0960 -> 369.3400 [ 1.02%] CTMark/consumer-typeset/<wbr>consumer-typeset.test<br>
256.1360 -> 253.9560 [ 0.86%] CTMark/mafft/pairlocalalign.<wbr>test<br>
459.5960 <- 462.5360 [ 0.64%] CTMark/SPASS/SPASS.test<br>
1265.6800 <- 1270.5560 [ 0.39%] CTMark/7zip/7zip-benchmark.<wbr>test<br>
589.8000 <- 591.7280 [ 0.33%] CTMark/lencod/lencod.test<br>
387.2960 <- 388.3840 [ 0.28%] CTMark/kimwitu++/kc.test<br>
924.1160 -> 921.7360 [ 0.26%] CTMark/Bullet/bullet.test<br>
497.1560 -> 496.2280 [ 0.19%] CTMark/ClamAV/clamscan.test<br>
brzycki@cc01 /work/brzycki/test-suite $ ~/git/me/llvm/litdiff build.upstream2/results.json build.D42717_newpatch/results.<wbr>json compile_time<br>
# left column: build.upstream2/results.json<br>
# right column: build.D42717_newpatch/results.<wbr>json<br>
# metric name: compile_time<br>
487.0560 <- 536.3320 [ 10.12%] CTMark/tramp3d-v4/tramp3d-v4.<wbr>test<br>
347.4120 -> 343.2440 [ 1.21%] CTMark/sqlite3/sqlite3.test<br>
256.1000 -> 253.9560 [ 0.84%] CTMark/mafft/pairlocalalign.<wbr>test<br>
588.3840 <- 591.7280 [ 0.57%] CTMark/lencod/lencod.test<br>
498.5240 -> 496.2280 [ 0.46%] CTMark/ClamAV/clamscan.test<br>
389.8320 -> 388.3840 [ 0.37%] CTMark/kimwitu++/kc.test<br>
1267.2280 <- 1270.5560 [ 0.26%] CTMark/7zip/7zip-benchmark.<wbr>test<br>
368.5280 <- 369.3400 [ 0.22%] CTMark/consumer-typeset/<wbr>consumer-typeset.test<br>
921.2680 <- 921.7360 [ 0.05%] CTMark/Bullet/bullet.test<br>
462.5440 -> 462.5360 [ 0.00%] CTMark/SPASS/SPASS.test<br>
<br>
The upstream and upstream2 builds both use DT for LVI analysis. In the case of `tramp3d-v4` we lucked out using DT analysis without causing a miscompile. I don't see a way to get that performance back.<br>
<br>
This patch also invalidates my proposed fix for <a href="https://reviews.llvm.org/D34135" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D34135</a> since we no longer have a valid DT before calling LVI in all instances.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D42717" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D42717</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>