Refactor computing lvaLongVars/lvaFloatVars #82331
Conversation
Compute them before loop hoisting, where they are actually used, not at the beginning of value numbering.
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsCompute them before loop hoisting, where they are actually used, not at the beginning of value numbering.
|
| unsigned floatVarsCount = VarSetOps::Count(this, lvaFloatVars); | ||
|
|
||
| if (floatVarsCount > 0) | ||
| if (!VarSetOps::IsEmpty(this, lvaFloatVars)) |
There was a problem hiding this comment.
It looks like lvaFloatVars doesn't account for SIMD variables (which end up in the same registers and I'd imagine have similar considerations). Is that expected and/or should they be tracked separately?
There was a problem hiding this comment.
This PR is simply a refactoring of existing code. I've opened #82351 to track this issue. It looks like SIMD type trees get treated as using int registers instead of float registers for the purpose of loop hoisting profitability.
There was a problem hiding this comment.
Thanks! Definitely not something I thought should be handled here, more just an observation/question of the code that was being refactored
|
@AndyAyersMS PTAL |
|
Actually shows a small but measurable TP improvement |
ghost
locked as resolved and limited conversation to collaborators
3 participants
Compute them before loop hoisting, where they are actually used, not at the beginning of value numbering.