[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