When calculating the specialization bonus for a given function argument, we recursively traverse the chain of (certain) users, accumulating the instruction costs. Then we exponentially increase the bonus to account for loop nests. This is problematic for two reasons: (a) the users might not themselves be inside the loop nest, (b) if they are we are accounting for it multiple times. Instead we should be adjusting the bonus before traversing the user chain.
This reduces the instruction count for CTMark (newPM-O3) when Function Specialization is enabled without actually reducing the amount of specializations performed.
testname | delta % non-LTO | delta % LTO |
ClamAV | -0.005 | 0.039 |
7zip | 0.012 | -0.007 |
tramp3d-v4 | -0.013 | -0.011 |
kimwitu++ | -0.011 | 0.146 |
sqlite3 | 0.04 | -0.445 |
mafft | 0.006 | 0.011 |
lencod | -0.02 | -0.023 |
SPASS | -0.006 | -1.06 |
consumer-typeset | 0.005 | -2.644 |
Bullet | -0.015 | -0.029 |
geomean | -0.001 | -0.406 |