Map correct fmt for mov instruction

[kunalspathak]

With #78879, we most likely exposed a problem in emitter, where mov would never go through emitIns_R_A.

I surveyed all the places that calls emitHandleMemOp() and hence emitMapFmtForIns() and the only place where mov can now end up to pass through emitIns_R_A() with wrong fmt. The format that would pass is IF_RRW_ARD (read/write) but it should be IF_RWR_ARD (since mov just writes to the register). The fix is to add a check in emitMapFmtForIns() to convert to right format.

Fixes: #79132

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With #78879, we most likely exposed a problem in emitter, where mov would never go through emitIns_R_A.

I surveyed all the places that calls emitHandleMemOp() and hence emitMapFmtForIns() and the only place where mov can now end up to pass through emitIns_R_A() with wrong fmt. The format that would pass is IF_RRW_ARD (read/write) but it should be IF_RWR_ARD (since mov just writes to the register). The fix is to add a check in emitMapFmtForIns() to convert to right format.

Fixes: #79132

Author:	kunalspathak
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[kunalspathak]

/azp run runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[kunalspathak]

@dotnet/jit-contrib @BruceForstall

[jakobbotsch]

Any idea why my jitstress runs in #78879 didn't hit this?

[kunalspathak]

Any idea why my jitstress runs in #78879 didn't hit this?

That's an interesting question. I tried locally to repro on the commit of #78879 and it repros for me. I also tried searching for logs of jitstress that was ran, but don't see that test anywhere. I am not sure why it didn't hit there.

[jakobbotsch]

Yeah, I don't know either. The testing I did was slightly different than normal jitstress: I disabled all heuristics in if-conversion and allowed if-conversion to convert all eligible if's into GT_SELECT, instead of only 25% of them (as in normal stress). But given the extensive failures in jitstress2 it's still very odd that I hit none of those even if this would be slightly different.

[jakobbotsch]

I took a closer look. The failures are a result of #78879 and #77728 together that I merged around the same time. I should've run another pass of testing after merging #77728.

[kunalspathak]

Ah, so #77728 code was also exercised for x64 after #78879. Makes sense.

[kunalspathak]

Ah, so #77728 code was also exercised for x64 after #78879. Makes sense.

Yep. I reverted #77728 and it doesn't repro anymore. Do you remember if you trigggered jitstress after #77728 was merged? Probably not. If it was the case, then it should have picked those changes.

[jakobbotsch]

Do you remember if you trigggered jitstress after #77728 was merged? Probably not. If it was the case, then it should have picked those changes.

Right, I didn't, that's why I was saying I should have run another pass of testing after that.