Refactoring store liveness update #80539
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsFollowing up 79182. When storing a variable means a spill, we are updating its liveness and setting the register to REG_STK. When the target is a register and not the stack, then we usually call genProduceReg which triggers the liveness update. This pr refactor similar code to avoid unintentional changes breaking either var home or var liveness and fix one case on arm 64 which was not considered (emitIns_S_R and emitIns_R_I don't update var home).
|
|
cc @dotnet/jit-contrib |
|
@kunalspathak are you able to take a look at this pr? All errors seem to be known issues. |
|
Seems like this affects the TP a bit. Can you please verify to see where it is coming from? Perhaps mark the method
|
|
There is no difference on TP when using |
|
Can you merge |
|
Changes looks good to me. Once we get the superpmi numbers, we can go ahead and merge. |
TP is overall positive: There is a timeout in OSX-x64 which seems to be non-related |
ghost
locked as resolved and limited conversation to collaborators
Following up 79182. When storing a variable means a spill, we are updating its liveness and setting the register to REG_STK. When the target is a register and not the stack, then we usually call genProduceReg which triggers the liveness update. This pr refactor similar code to avoid unintentional changes breaking either var home or var liveness and fix one case on arm 64 which was not considered (emitIns_S_R and emitIns_R_I don't update var home).