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

    <tr>
        <th>Summary</th>
        <td>
            [LegalizerHelper] Bug in insert position iterator
        </td>
    </tr>

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

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

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

<pre>
    For my custom backend, I've following GMIR input to legalizer:

```

  %1:_(s32) = COPY $r8
  %0:_(s16) = G_TRUNC %1:_(s32)
  %2:_(s16), %3:_ = G_SDIVREM %0:_, %0:_
  %4:_(s16) = G_INTRINSIC intrinsic(@llvm.custom.fma), %2:_(s16), %3:_(s16), %2:_(s16)
 %7:_(s32) = G_ANYEXT %4:_(s16)
  $r8 = COPY %7:_(s32)
```

I've following legalization rule for G_SDIVREM:

```
  getActionDefinitionsBuilder(
 {G_UDIVREM, G_SDIVREM})
      .clampScalar(0, s32, s64)
 .scalarize(0)
      .customFor({s32, s64});
```

Therefore, legalizer tries to widen G_SDIVREM operation to s32. Then, it inserts G_TRUNC to truncate %2, %3 so they can be consumed by the following llvm.custom.fma intrinsic.

The problem occurs with placement of G_TRUNC operations in LegalizerHelp.cpp. Here's the existing logic:

```
  case TargetOpcode::G_SDIVREM:
    Observer.changingInstr(MI);
 widenScalarSrc(MI, WideTy, 2, TargetOpcode::G_SEXT);
    widenScalarSrc(MI, WideTy, 3, TargetOpcode::G_SEXT);
    widenScalarDst(MI, WideTy);
 //MIRBuilder.setInsertPt(MIRBuilder.getMBB(), --MIRBuilder.getInsertPt());
 widenScalarDst(MI, WideTy, 1);
    Observer.changedInstr(MI);
    return Legalized;
```

After widening, we must insert 2 G_TRUNC operations. First G_TRUNC is inserted at correct position. widenScalarDst() increments next insertion position. Therefore, the second widenScalarDst() inserts 2nd G_TRUNC 1 instruction too late. This leads to following incorrect code:

```
  %2:_(s16) = G_TRUNC %10:_(s32)
  %4:_(s16) = G_INTRINSIC intrinsic(@llvm.custom.fma), %2:_(s16), %3:_(s16), %2:_(s16)
  %3:_(s16) = G_TRUNC %11:_(s32)
```

My proposed fix is in the comment above. This applies to G_UDIVREM as well.

To submit the patch, I need a test. But I'm unable to reproduce this on backends other than my custom backend. So what's the right way to submit this test?
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJzMVktv2zgQ_jXyZRBBpiw_Dj74UacG1mmRuLvtKaCoscQtRQokFdf99QtSkh-RgwX2tIGAyOTMN59mvhmSGsNziTgPkmWQrAe0toXS80pTy39SU1A9SFV2mm-UhvIErDZWlZBS9hNlFpAVbAMyeUM4KCHUkcscHnfbZ-Cyqi1YBQJzKvhv1EG8CCL_jKP28T8BApIMg3jxGpCpiUlAZhDEa1h9-foDAjLS084o6oyG487o8XX__O1p1YfofMiNj-MbkCR2i63_y3r75_On3RX-6vLegozuBd4-7Z-3Ty_bFXBpNZeGs4BMg1EkxFsZNnkKDyW9hP2Yy_vFd5bRwi1O-jl6fF08_fj0fd8n2VIf6el1Mt9h9IvRK2ZbPmq5kqBr4fb0JW13iwqQo10w57LGA5fcvZllzUWG2uXIfc9k-fj6rQUhqyvEybqj7_5CJmhZvTAqqHONnK0nvwIzHrWWofH7_Dc2Jtfuvg4b5eNOlleuTZx42U_CvkCNB6XRmZ71C1ZzNE7SR56hvJKOqlA3CbLKkQthX6B0ztwClwa1NWelWgVW15JRi02lWxmAUWALPAGjElIEpqSpS8wgPbn165Lc6usiv_BMHyqtUoElKMZqbeDIbQGVoAxLlBbU4UznzN0Al_BH97GfUVQhq6oQPqPLw8R4EviLG-s5qJyzD4rPqEHYU52j_VIxlaGzixfvNOOq8yU1qN9Qh6ygMucy30pjXaV223Ntmmw3AnjRrN1cwV88w_3JvfkU3o336fv-ggPw71Dxf4FaG9uD6iwDsgnIZrd9btUfGrRbr4ivjdN5I0e7Wy6dSpsp8PBwu3nl5S3upOcekRUMb3jfphyzexkHAI221hc9ZHf7ZHGwqBsCXOYu1hGhrE0neiB3ZBbChmtjzzvctNaYAbXAlNbILFTK-LER9j_QDT8umfZaNiDxVxfQteDF8aaNnXoNMiWzjwCbNiUyO1MbulWra9b2tgJBLTpgbkAgzfw0uDQmlx37Tjp3uqM33XvnWHT3IPsfnEF90x733iH8TjK7kxtNlTKYwYH_aqrvi8NU6WcTTdVbl2NaVaKduefDAqiBIwrRDTsFpk5Lbj1IRS0r_KUEJDpBgUVjQ1jW1t9TSqglTQU6RI2VVlnNEKyLpWR3qTGgbOHmfUFl_8oTwouCY0HteShqnhcWjvTkx39HhhsfO4g3g2weZ7N4Rgc4H06SKRlPk2Q4KOazURylh0l0mJJoMksjRJYmCWazIYsoHY0HfE4ikkSz4SyaJEkyDDEaj6PxiMQxZdGUxsEowpJyEfp6K50PuDE1zofJbDIcDwRNURh_syNE4hH8bkCIu-jpuXN6SOvcOMFwY80FxnIr_JXw5kRAHSRrWNZO6l2Pd_0G3LoWV3pQazEvrK2M6wA__3JuizoNmSoDsnEx2n8PlVZ_I7MB2XhmJiCblvrbnPwTAAD__0f_KTc">