Do not consider InUse registers for assigning to consecutive candidates#95612
Do not consider InUse registers for assigning to consecutive candidates#95612kunalspathak merged 5 commits intodotnet:mainfrom
Conversation
…consecutive register refposition
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsWhen checking if consecutive registers are available, also take into account the information if registers are in use at the same location. If that is the case, do not consider it as candidate for consecutive register allocation. I also experimented with 6e8b096 to not spill a register that is already assigned to the consecutive registers because that could involve lot of moving around, since the next consecutive registers might have to be in different registers than the ones they were originally obtained. It doesn't make much difference in the codegen of the example of the code that was introduced in #95513 . I might revert depending on how CI and TP impact is. 
|
kunalspathak
changed the title
This reverts commit ec31dfe.
|
@dotnet/jit-contrib |
src/coreclr/jit/lsra.cpp
Outdated
| else if (assignedInterval->getNextRefPosition()->needsConsecutive) | ||
| { | ||
| // if next refposition is part of consecutive registers and there is already a register | ||
| // assigned to it then do not reassign for currentRefPosition, because with that, other | ||
| // registers for the next consecutive register assignment would have to be copied to | ||
| // different consecutive registers since this register is busy from this point onwards. | ||
| continue; |
There was a problem hiding this comment.
Would it be possible to run out of registers if there are a number of instrinsics defining consecutive registers and later using them, and in between we don't allow spilling them?
There was a problem hiding this comment.
Yes, that was exactly on my mind and hence wanted to check if we find a case like that in CI. I think I will revert this portion.
There was a problem hiding this comment.
On a second thought, I could actually have it record the spill cost as costlier, so those registers will be preferred if no other option is available. With that we do eliminate the extra copies and the code looks much better:
main vs. latest changes
skip spilling consecutive vs. latest changes
3 participants
When checking if consecutive registers are available, also take into account the information if registers are in use at the same location. If that is the case, do not consider it as candidate for consecutive register allocation.
I also experimented with 6e8b096 to not spill a register that is already assigned to the consecutive registers because that could involve lot of moving around, since the next consecutive registers might have to be in different registers than the ones they were originally obtained. It doesn't make much difference in the codegen of the example of the code that was introduced in #95513 . I might revert depending on how CI and TP impact is.
Details: #95513 (comment)