We don't want to decay hot callsites to import chains of hot
callsites. The same mechanism is used in LIPO.
Details
Diff Detail
Event Timeline
(As discussed offline, Piotr will test on SPEC and get back with performance data).
test/Transforms/FunctionImport/hotness_based_import.ll | ||
---|---|---|
38 | Comment doesn't make much sense - we are checking that they aren't imported. |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
385 | I rather express this differently: using different factors for the hotness. |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
344 | just to make sure - you want to apply the threshold: lines if (IsHotCallsite) Threshold = Threshold * ImportHotInstrFactor; else Threshold = Threshold * ImportInstrFactor; here, and don't do any threshold changes in the while loop? (So worklist will only contain FunctionSummary - because threshold and my bool won't be needed) If so, then it seems like a good idea! |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
344 | Right: doing all the threshold management at the same place. |
I have some initial results. It looks like because inliner doesn't know how to inline hot callsites, then most of the SPEC benchmarks have the same binary as current trunk (with hot heuristic).
But on the google branch with smarter inliner there is clear win in povray, about +0.5% compared to current trunk with hot heuristic, over all other benchmarks that produced different binary are not much different.
So the question is - should I temporary set the hot-evolution-factor to the same as normal evolution factor? So this way We won't import more functions that inliner won't inline, and then when new inliner will make it to trunk, to switch it to 1.0
Can you enable your importing stats to see how many extra funcs we import in trunk?
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
268–269 | Change not needed now | |
289 | These few lines no longer need changing | |
376–377 | No need to change these lines, just remove the threshold adjustment (makes the actual functional change clearer without other changes). |
So the question is - should I temporary set the hot-evolution-factor to the same as normal evolution factor? So this way We won't import more functions that inliner won't inline, and then when new inliner will make it to trunk, to switch it to 1.0
I'm fine designing the importer independently knowing that the inliner will be updated at some point to match, even if it means that in the meantime we import more than necessary when PGO is enabled.
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
289 | I think they need: I am ussing isHotCallsite later, and it also makes code cleaner |
These are the numbers of imported functions for povray
trunk_without_hot trunk trunk_hot_chaians
1738 1863 1876
So we import 13 functions more. This is kinda expected, there should not be many hot chains
Change not needed now