Compared to the optimized code with branch conditions never frozen,
limiting the type of freeze's operand causes generation of suboptimal code in
some cases.
I would like to suggest removing the constraint, as this patch does.
If the number of freeze instructions becomes significant, this can be revisited.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
678 | Oh, hmm, I misintepreted this comment, and didn't read the code carefully enough. The "if" is actually a heuristic that suppresses potential optimizations. Do you have any idea what the actual compile-time impact would be if we just recursed over all casts? |
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
678 | I ran a test, and actually it brought a slight speedup when compiled with -O3 (without LTO): +-----------------------------------------------+-------+-------+------------+ | unit:sec. | base | cast | speedup(%) | +-----------------------------------------------+-------+-------+------------+ | CTMark/7zip/7zip-benchmark.test | 90.18 | 89.83 | 0.39% | | CTMark/Bullet/bullet.test | 63.11 | 62.92 | 0.31% | | CTMark/ClamAV/clamscan.test | 27.00 | 26.98 | 0.05% | | CTMark/SPASS/SPASS.test | 26.27 | 26.14 | 0.52% | | CTMark/consumer-typeset/consumer-typeset.test | 19.73 | 19.74 | -0.02% | | CTMark/kimwitu++/kc.test | 26.60 | 26.51 | 0.37% | | CTMark/lencod/lencod.test | 34.64 | 34.65 | -0.03% | | CTMark/mafft/pairlocalalign.test | 16.24 | 16.24 | 0.00% | | CTMark/sqlite3/sqlite3.test | 24.61 | 24.68 | -0.27% | | CTMark/tramp3d-v4/tramp3d-v4.test | 49.35 | 49.24 | 0.22% | +-----------------------------------------------+-------+-------+------------+ Would it be a right direction if I remove this condition in a separate patch? |
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
678 | Compile time != run time |
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
678 | The table depicts compile time. Compilation becomes slightly faster (or almost equivalent, assuming that they are errors) if the conditions are removed, interestingly. |
llvm/lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
678 | http://llvm-compile-time-tracker.com/compare.php?from=03116a9f8c2fc98577e153083aaf9b6a701ab8f9&to=503a232ea5a630ddacde3ba01498776b61c4c8d4&stat=instructions |
Oh, hmm, I misintepreted this comment, and didn't read the code carefully enough. The "if" is actually a heuristic that suppresses potential optimizations.
Do you have any idea what the actual compile-time impact would be if we just recursed over all casts?