[LSRA] Further tuning of preferencing is needed #11959
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
tenet-performance
Performance related issue
LSRA preferencing was improved with dotnet/coreclr#19429, but additional tuning is needed.
On x86, the
Span.IndexerBench
benchmark, the changes caused additional spill in some key methods due to different allocation choices. Specifically:Span.IndexerBench:TestSameIndex1(struct,int,int):ubyte
- V02 gets spilledSpan.IndexerBench:TestCoveredIndex2(struct,int,int):ubyte
- V02 gets spilledSpan.IndexerBench:TestIndexer6(struct):ubyte
- V02 gets spilledSpan.IndexerBench:TestCoveredIndex3(struct,int,int):ubyte
- V04 gets spilledAnother area to investigate (probably independent from the above), is that it seems logical that
RefPosition::getRangeEndRef()
should only return 'nextRefPosition' if it is alastUse
and otherwise returnlastRefPosition
, but that tends to excessively lengthen the range for heuristic purposes. Another option might be to iterate to the nextlastUse
, but that might have excess throughput impact.category:cq
theme:register-allocator
skill-level:expert
cost:large
The text was updated successfully, but these errors were encountered: