[PATCH] D53245: Teach the DominatorTree fallback to recalculation when applying updates to speedup JT (PR37929)
Chijun Sima via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 25 10:08:10 PDT 2018
NutshellySima added a comment.
> The constant "40" selected is based on the previous table and additional tests on "25" and "50" (see below),
>
> | α | y/clang | y/sqlite | y/oggenc |
> | 0/baseline | 33.20% | 25.60% | 28.40% |
> | 20 | 20.70% | 21.70% | 22.50% |
> | 25 | 20.40% | --- | --- |
> | 30 | 13.10% | 23.10% | 23.70% |
> | 40 | 13.60% | 24.10% | 24.90% |
> | 50 | --- | 25.60% | --- |
> | 55 | 14.20% | 26.00% | 28.00% |
> | 40 (n>=100) | 13.30% | 21.20% | 24.50% |
> |
>
> I'll test `n>=200/300/400` to see whether it is better.
For the oggenc case, `n>=200/300` doesn't seem to be better.
| α | y/oggenc |
| 40 (n>=100) | 24.5% |
| 40 (n>=200) | 25.8% |
| 40 (n>=300) | 27.2% |
|
Based on the fact that the current heuristic `40 (n>=100)` outperforms the one updating directly without recalculation `0/baseline` on `clang/sqlite and oggenc`, I think the current heuristic is conservative enough and expected not to harm performance of any input significantly. :)
Repository:
rL LLVM
https://reviews.llvm.org/D53245
More information about the llvm-commits
mailing list