JIT: very simple cloning heuristic #108771
Conversation
Avoid cloning large loops. We compute loop size by counting tree nodes of all statements of all blocks in the loop. If this is over a threshold, we inhibit cloning. Threshold value was chosen based on distribution of unrestricted cloned loop sizes in the benchmark run_pgo collection.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
cc @dotnet/jit-contrib Distribution of unrestricted loop clone sizes (from x64 benchmarks.run_pgo, units are tree node counts). There aren't many large loops and cloning them quite likely has a poor size/tp/perf tradeoff. So let's try not cloning them and see how it goes.
I played around with more "sophisticated" heuristics (some vestiges still there in this PR) where I also tried to compute the size reduction in the cloned loop and the performance impact using block weights. But without access to My proposal is to merge this (or something like it) and adjust as needed after the fact based on perf lab and other data. |
|
@BruceForstall PTAL |
No diffs in any benchi/benchf(w/pgo) ... there are some in Bytemark's |
Fixes from review Co-authored-by: Bruce Forstall <[email protected]>
|
Ah, right, ludcmp is the case I was thinking about. |
|
Some huge diffs. Especially in libraries_tests. And in ludcmp, as expected. Surprisingly, some size regressions? Maybe cloning was enabling some size-improving optimizations (and getting rid of the cloning overhead)? |
Avoid cloning large loops.
We compute loop size by counting tree nodes of all statements of all blocks in the loop. If this is over a threshold, we inhibit cloning.
Threshold value was chosen based on distribution of unrestricted cloned loop sizes in the benchmark run_pgo collection.