| commit | cceea2482e5873470eea4782b14d10ef206de9ba | |
| author | Rick Lavoie <rlavoie@fb.com> | |
| Fri, 10 Sep 2021 23:24:51 +0000 (10 16:24 -0700) | ||
| committer | Facebook GitHub Bot <facebook-github-bot@users.noreply.github.com> | |
| Sat, 11 Sep 2021 00:06:42 +0000 (10 17:06 -0700) | ||
| tree | 648064180e609140aa44af116ebe150581b1d624 | treesnapshot (tar.gz zip) |
| parent | afb570e56c42a83680e9fe187a7998671f9664b3 | commitdiff |
Rematerialization shouldn't ever return a spill instruction
Summary:
When finding an instruction to rematerialize a spill from, we usually
look "through" a spill instruction. The only exception is if the
source of the spill is a physical register. We cannot proceed past
this past, so we just return the instruction. However, this is
incorrect, since it means we return a spill for
rematerialization. This ends up "rematerializing" a spill, which
causes the state tracking to get out of sync. In this case, instead
return a synthesized copy, since we can rematerialize from copying
from the source physical register.
Reviewed By: mofarrell
Differential Revision: D30869836
fbshipit-source-id: 795ebeed011ea458c05dfb2d69818ad19b6e7826
Summary:
When finding an instruction to rematerialize a spill from, we usually
look "through" a spill instruction. The only exception is if the
source of the spill is a physical register. We cannot proceed past
this past, so we just return the instruction. However, this is
incorrect, since it means we return a spill for
rematerialization. This ends up "rematerializing" a spill, which
causes the state tracking to get out of sync. In this case, instead
return a synthesized copy, since we can rematerialize from copying
from the source physical register.
Reviewed By: mofarrell
Differential Revision: D30869836
fbshipit-source-id: 795ebeed011ea458c05dfb2d69818ad19b6e7826
| hphp/runtime/vm/jit/vasm-graph-color.cpp | diffblobblamehistory |