<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/152816>152816</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [M68k] Miscompile: `COPY` and `copyPhysReg()` do not respect live CCR register
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          dansalvato
      </td>
    </tr>
</table>

<pre>
    The easiest way to reproduce this is with the following IR:

```llvm
target triple = "m68k-freestanding"
define i8 @atomicrmw_add_i8(i8 %val, ptr %ptr) {
  %old = atomicrmw add ptr %ptr, i8 %val monotonic
  ret i8 %old
}
```

Build with `-mcpu=M68020` and notice this block in the result:

```m68k
.LBB0_1:
        move.b  %d2, %d3
        add.b   %d1, %d3
        cas.b %d0, %d3, (%a0)
        move.b  %d0, %d3
        sub.b   %d2, %d3
        seq     %d2
        and.b   #1, %d2
        cmpi.b  #0, %d2
        move.b  %d0, %d2 ; <------ Kills CCR
        beq     .LBB0_1
        bra     .LBB0_2
```

Here is the MC:

```
 bb.1.atomicrmw.start:
    successors: %bb.2(0x04000000), %bb.1(0x7c000000)
 liveins: $a0, $bd0, $bd1, $bd2
  
    $bd3 = COPY $bd2
    $bd3 = ADD8dd killed $bd3, $bd1, implicit-def dead $ccr
    $bd0 = CASARI8 killed $bd0, killed $bd3, $a0 :: (load store monotonic monotonic (s8) on %ir.ptr)
 $bd3 = COPY $bd0
    dead $bd3 = SUB8dd killed $bd3, killed $bd2, implicit-def $ccr
    $bd2 = SETd8eq implicit killed $ccr
    $bd2 = AND8di killed $bd2, 1, implicit-def dead $ccr
    CMP8di 0, killed $bd2, implicit-def $ccr
    $bd2 = COPY $bd0
    Beq8 %bb.1, implicit killed $ccr
    BRA8 %bb.2
```

I wrote my own patch that mitigates this, but it's more of a workaround. In `copyPhysReg()`, if CCR is live *and* the destination is a data register, I back up the CCR and restore it after the copy.

In my opinion, this issue is severe enough that it warrants merging a workaround patch, but I'd like a second opinion before I submit something.

The workaround could be improved if it's somehow possible to re-allocate the destination to an address register, because copying to address registers doesn't affect CCR. But I think the preferable solution would be to prevent `COPY` from ever being emitted in locations where the CCR is live.
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyMVk9v47gO_zTKhaihyHFiH3Jwkle84r3uDjqzhz0NZItJtJUljyQn22-_oJx_bTqLCQxUFSmSvx9JUTIEvbOIS1asWLGZyCHunV8qaYM0BxndpHHqbfltj4AyaAwRjvINogOPvXdqaBHiXgfQAY467iHuEbbOGHfUdgdPLyyvGU_fnI-fMYeO8TpKv8MI0eveILB8A0yIbl6-Pmw9YojSKm13TAjGa4VbbRF0CWzGZXSdbn13_C6V-q5LJkoSiOIgDRNr6KOn__romaiALVaM10A7zqjk52IApFLv1NdwsQSdsy46q9t03GM8yZxRhGaxucU0QlwN2qiRBjbnD13bDyzfPM9LLkgJpFVgXdRnzhrj2lfQNpHmMQwm3tNFlDBeZ_9frfj36Vlede6AWcN4xUShBIVOi3wUSqUusukHWStD1qQNfpWkRclEITkT1Sce-AcrYWh-6j3gj4tkDMeew8kv0ZxEbdfrs4x_kH0egACWr4Dl64f0g_9pYwKs1y_joSY5P7M1bnl52RL3WfsveqTypSQ8r-8TQPlvmmyaXeomC1H6U6oAAMLQthiC84HlNQXZNJlgouR_8xlPPyJ1jJ8sJdGivYp4DUYfUNuTgZk8wZ016rqaXlZiLOnRe9rJU2Wvf__y563GO2G92ZRKwas2BtVJ8N627nqjWx0fFG5BoUxabetvbfHRUf21fnkq3xlLgX5mXdKZekRWGicVhOg8XjvsZsVEGUrqW2eJLe2zsY8phE-B8lNw53DPGl__WH2K9nZD3IG-xytGa__5pkr8cVG-MfOpfv3bplT63tmv0Lx-_kJn7-j89Wjv2Vnhj_Jafet_x7F6qctLFd-1yxMcvYsI3Ru4o4VexpZufRmh01HvZMSQbjdy0wwRdGRiEaCjjLstSDg6_yq9G6zK4MnSTdm6_u3L_i284C7dQhU5oyi31NfUm9QdwEQtrWKiTq2qMERtZdTOkoYEJaMEjzsdIqa7_Aka2b7C0Cd9skQXsMex-nQEuY3ok5AiyE74bILWa6udJTOn8RaGdEsEPNB9gdYNuxNuTTPRe2ljgA79jgbfLcyRozMfT0wsFBj9iiAhYOusOnuDBrcU2hOEoel0hOA6jHttd6fYaAzf2G3dYBQ0SOn07oCKGDvxTUf37gi9C0E3BseR_SCNca2MeEdhdCAtDUSPIbyjscFWDmHkiKCR5ge1AMphsEwsiNQttpHozmBFeIlA-5oc9h636CWFE5wZkuPjGUR0JD-gjVQTVMM0M7fedUCcQ4PkHTsdIyG1kJBoZwMc95STc5ZP9ZJN1DJXVV7JCS6ni2I2r8pCTCf7ZSXKRT5tUU6rplK4nc9zPm9FWU6L-bQoq4leCi4KXvKK82khplk-m-VtW83LpimLvGrYjGMntcnoMZM5v5ukAllOC1FO5xMjGzQhvamEsHgcy4feMsVm4pd06KEZdoHNuNEhhquZqKNJj7FnGvvFBp51aF3Xa4PpAr0SQ7X8k94B5eidQaXeUy5S9xAz53xNBm-W-xh7mjdMPDLxuNNxPzRZ6zomHtMTbfzz0Hv3F7aRiccEIjDxeEJ5WIp_AgAA__9Jmwv4">