Open amanasifkhalid opened 1 week ago
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch See info in area-owners.md if you want to be subscribed.
This is another one exposed from https://github.com/dotnet/runtime/pull/107714. Marking as 10.0
This is another one exposed from #107714. Marking as 10.0
I confirmed that the recent fixes in #107714 and https://github.com/dotnet/runtime/pull/107493 is exposing these problems. In this example, the symptoms are slightly different. Here is what we want to resolve.
V645: f18 -> f16 (float)
V646: f19 -> f17 (float)
V642: f16 -> f18 (double)
So, basically, in current block, value of V645
is in f18
but we want it to be in f16
in successor block, so we need to add a resolution of moving f18
to f16
at the end of source block. Given all the resolution needed, ideal resolution should look something like this (in that order):
a. V642: f16 -> f0 (f0 is a temporary resolution register)
b. V645: f18 -> f16
c. V646: f19 -> f17
d. V642: f0 -> f18
First, we free up f16
, however, since it held double V642
, we also want to free up f17
. Next, we move f18 -> f16 (float V645)
and f19 -> f17 (float V646)
because both are float
. Lastly, we move the value of double V42
from f0 -> f18
.
Before my prior fixes in #107714 and #107493, we would do the following resolution:
a. V646: f19 -> f17 (overwritten upper half of V642)
b. V642: f16 -> f0
c. V645: f18 -> f16
d. V642: f0 -> f18
As we see here, we first resolve V646
by moving f19 -> f17
. However, since f16/f17
was holding double V642
, we have just overwritten the upper half of V642
, which is wrong. Further resolutions do not fix the problem and we end up scrambling the values held in registers.
My fix in #107714 and #107493, basically tries to prohibit such situation by and exposed these bugs:
(This is the reduced repro)
cc @dotnet/jit-contrib