tree ebe7980e5cbdb7bea877ff4dc8c95cc22204f260
parent f4b175aeed2975815f9425d52a52360aeceeb1e2
author Christoffer Quist Adamsen <christofferqa@google.com> 1691751278 +0200
committer Christoffer Quist Adamsen <christofferqa@google.com> 1691751278 +0200

Avoid conflating register sets at move-exception

In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.

Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).

The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.

Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.

The instructions must be laid out in sequence as:

  move r11, r3
  move r1, r11

When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:

  move r1, r11
  move r11, r3

Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.

Bug: b/293501981
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74