[PATCH] D42717: [JumpThreading] sync DT for LVI analysis (PR 36133)

[Daniel Berlin via llvm-commits]

Interesting.
Do you have a profile of tramp3d-v4 before and after.
This should hopefully just be something stupid we can fix

(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.
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)

On Fri, Feb 9, 2018 at 9:10 AM, Brian Rzycki via Phabricator <
reviews at reviews.llvm.org> wrote:

> brzycki added a comment.
>
> @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`:
>
>   brzycki at cc01 /work/brzycki/test-suite $ ~/git/me/llvm/litdiff
> build.upstream/results.json build.D42717_newpatch/results.json
> compile_time
>   #  left column: build.upstream/results.json
>   # right column: build.D42717_newpatch/results.json
>   #  metric name: compile_time
>       493.8600 <- 536.3320     [  8.60%]  CTMark/tramp3d-v4/tramp3d-v4.
> test
>       336.3600 <- 343.2440     [  2.05%]  CTMark/sqlite3/sqlite3.test
>       373.0960 -> 369.3400     [  1.02%]  CTMark/consumer-typeset/
> consumer-typeset.test
>       256.1360 -> 253.9560     [  0.86%]  CTMark/mafft/pairlocalalign.test
>       459.5960 <- 462.5360     [  0.64%]  CTMark/SPASS/SPASS.test
>      1265.6800 <- 1270.5560    [  0.39%]  CTMark/7zip/7zip-benchmark.test
>       589.8000 <- 591.7280     [  0.33%]  CTMark/lencod/lencod.test
>       387.2960 <- 388.3840     [  0.28%]  CTMark/kimwitu++/kc.test
>       924.1160 -> 921.7360     [  0.26%]  CTMark/Bullet/bullet.test
>       497.1560 -> 496.2280     [  0.19%]  CTMark/ClamAV/clamscan.test
>   brzycki at cc01 /work/brzycki/test-suite $ ~/git/me/llvm/litdiff
> build.upstream2/results.json build.D42717_newpatch/results.json
> compile_time
>   #  left column: build.upstream2/results.json
>   # right column: build.D42717_newpatch/results.json
>   #  metric name: compile_time
>       487.0560 <- 536.3320     [ 10.12%]  CTMark/tramp3d-v4/tramp3d-v4.
> test
>       347.4120 -> 343.2440     [  1.21%]  CTMark/sqlite3/sqlite3.test
>       256.1000 -> 253.9560     [  0.84%]  CTMark/mafft/pairlocalalign.test
>       588.3840 <- 591.7280     [  0.57%]  CTMark/lencod/lencod.test
>       498.5240 -> 496.2280     [  0.46%]  CTMark/ClamAV/clamscan.test
>       389.8320 -> 388.3840     [  0.37%]  CTMark/kimwitu++/kc.test
>      1267.2280 <- 1270.5560    [  0.26%]  CTMark/7zip/7zip-benchmark.test
>       368.5280 <- 369.3400     [  0.22%]  CTMark/consumer-typeset/
> consumer-typeset.test
>       921.2680 <- 921.7360     [  0.05%]  CTMark/Bullet/bullet.test
>       462.5440 -> 462.5360     [  0.00%]  CTMark/SPASS/SPASS.test
>
> 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.
>
> This patch also invalidates my proposed fix for https://reviews.llvm.org/
> D34135 since we no longer have a valid DT before calling LVI in all
> instances.
>
>
> https://reviews.llvm.org/D42717
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180209/098abc67/attachment.html>