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

    <tr>
        <th>Summary</th>
        <td>
            MemOperands not updated during ISel argument copy elision, may lead to miscompile
        </td>
    </tr>

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

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

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

<pre>
    Reproduce with: 06eedffe0d27
```
llc bbi-94617_3.ll -o - -debug
```
[bbi-94617_3.ll.gz](https://github.com/llvm/llvm-project/files/15010509/bbi-94617_3.ll.gz)

If we look at the debug printouts, in "Initial selection DAG:" we get
```
SelectionDAG has 29 nodes:
  t0: ch,glue = EntryToken
 t2: i32,ch = CopyFromReg t0, Register:i32 %0
  t3: i16 = truncate t2
 t5: i32,ch = CopyFromReg t0, Register:i32 %1
  t6: i16 = truncate t5
 t8: i32,ch = CopyFromReg t0, Register:i32 %2
  t9: i16 = truncate t8
 t11: i32,ch = CopyFromReg t0, Register:i32 %3
  t12: i16 = truncate t11
    t14: i32,ch = CopyFromReg t0, Register:i32 %4
  t15: i16 = truncate t14
    t17: i32,ch = CopyFromReg t0, Register:i32 %5
  t18: i16 = truncate t17
  t21: i16,ch = load<(load (s16) from %fixed-stack.0)> t0, FrameIndex:i64<-1>, undef:i64
  t23: i64 = Constant<0>
      t24: ch = store<(store (s16) into @v_781, align 1)> t21:1, t21, GlobalAddress:i64<ptr @v_781> 0, undef:i64
    t26: ch = store<(store (s16) into %ir.param.addr, align 1)> t24, Constant:i16<666>, FrameIndex:i64<-1>, undef:i64
  t28: ch = X86ISD::RET_GLUE t26, TargetConstant:i32<0>
```
Especially consider
```
t21: i16,ch = load<(load (s16) from %fixed-stack.0)> t0, FrameIndex:i64<-1>, undef:i64
```
and
```
t26: ch = store<(store (s16) into %ir.param.addr, align 1)> t24, Constant:i16<666>, FrameIndex:i64<-1>, undef:i64
```
The load and store both access "FrameIndex:i64<-1>", but the MemOperands look like
```
load (s16) from %fixed-stack.0
```
and
```
store (s16) into %ir.param.addr, align 1
```
so they access exactly the same memory on the stack, but according to the MemOperands it looks like they access different objects? I think this is wrong.

If we look further at the debug printouts at "MI Scheduling" we get
```
SU(0):   %6:gr16 = MOV16rm %fixed-stack.0, 1, $noreg, 0, $noreg :: (load (s16) from %fixed-stack.0, align 16)
  # preds left       : 0
  # succs left       : 1
  # rdefs left       : 0
 Latency            : 4
  Depth              : 0
  Height             : 4
  Successors:
    SU(2): Data Latency=4 Reg=%6
  Single Issue : false;
[...]
SU(2):   MOV16mr %7:gr64, 1, $noreg, 0, $noreg, %6:gr16 :: (store (s16) into @v_781, align 1)
  # preds left       : 2
  # succs left       : 0
  # rdefs left       : 0
  Latency            : 1
  Depth              : 4
  Height             : 0
 Predecessors:
    SU(1): Data Latency=4 Reg=%7
    SU(0): Data Latency=4 Reg=%6
  Single Issue       : false;
SU(3):   MOV16mi %fixed-stack.0, 1, $noreg, 0, $noreg, 666 :: (store (s16) into %ir.param.addr, align 16)
  # preds left       : 0
  # succs left : 0
  # rdefs left       : 0
  Latency            : 1
  Depth : 0
  Height             : 0
  Single Issue       : false;
```
So there is no dependency whatsoever between the load, SU(0) and the store SU(3), even if they access the same memory.

On my downstream target this then lead to a miscompile when the scheduler choose to change the order of the load and store.

I think the problem is that SelectionDAGISel::LowerArguments and tryToElideArgumentCopy does rewrites and change the FI used in some instructions, but they leave the MemOperands unchanged.

This seems to be old but it recently lead to a miscompile for my target when the load and store suddenly executed in the wrong order.

</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzMWG9v4j4S_jTmzagocf4AL3jBQtlD2tWett3TvVs58STx1bGR7ZTlPv3JDgRKQf1zOt2vqmhqj2eeeR7bM4FZK2qFOCfZF5KtRqxzjTbzVjwxlI2WLapRofl-_hO3RvOuRNgJ15BkAVGOyKsKI04nJFqRaEHy6PAb_pWyhKIQd7M0jye_k7GUcKfhDu44Fl19dQnJvrxcMa7_TbIVodPGua0lyYLQNaHrWrimK8albgldS_l8_HO3NfpfWDpC15WQaAldx1kUR1k0I3T92jWdHeKGz00FOwSp9RMwB65BCEhha4RyunOW0CUIBYTSjRJOMAkWJZZOaAWrxdcAj3ofNbqr-T0czVeLr9AwC3QGSnMMmQULABd5dsuG0GUtOwSSrOBeObN_1E-oDlaOeiORUEKXZRNslnq7Xxvd_sTa-6BL-Im1sA4NSRYioUBoFg1BkrA-zsNSZzpVMofe7cF_9in_8eA_v-4_O_qffso_HfzPrvufHv3H8acCJEOAmF6PEA85eqP0U1HSU5TsRpT0PMrkU1GyU5TpjSiTwYTGB5NTDKkZJ8mS0Kl_AkKn1k_PoDK69QEq8Qf5nXWsfBpH_iwl9wcwa8Na3CiOfzycPCXJ8i4myb2f6xTH6jA8RO-3Y54eklPWMeVIsoz8ooEJb5n2pyMYWqcN9hDD4xlGf2KBpNHz78k09mGZFLWC-Agz5Bsm_CNdwlepCyYXnBu0dkC9debkJbmH6EYGHln-EWQ0E2a8ZYa1Y8a5uYYw9YMnLhZenGSZ5_mByA-TPD0D-M9pvnlY-WsnWfy8f_z99duv-5ADXcIjMzW688gJfaHFxa12b7dYCiblHkqtrOBortr9PzfZBRSm-A2If2kVL9A-NhgIBKZ4DxYK7RpgZYnW-jp127u_TKDo-jr3HdsfWzRMcdvXPyme8HpRf49KH2H8w8RedaJ9Gvtj4viHlU7uQ2qWtQgtttrsQat-yMM8ps_KUhsuVA1Ov-JCuECHDXy8CMFFVaFB5UAXvuOwJFnDBlwj1JP_tCAs7IxW9fhGi1F1xjVobrQafphQ-n0DD2WDvJNC1W81F78InfZHxN9IhGZ-L9fmcO1___GPODfXztQSwg1IaKq0wdo_R-cD0F8T8O5DOoiVDx2Wx5PA1qDfYVi5_jqH0EieW9iuLF9ZxOcWhmN108c35lCVezj78dPDJbjCrWsALucHCH9DUTfu1fyw_qEL8mtz3rEBBOrpgfoVc-wIhCSr1JdmkqyCHkc3QtUSYWNtaPAWUDFpkSRfhjZ4PB77xvckLB2EDUK2xvM-CQLn6dsa9s_nO-Io6Ucq51tS0jeljN4t5S0t4ze0TN_Q8uj_7wY53hQzflPMycWK6JPyn5C93ATBaXKhuvjE8fXPef625Lfv3P_qGP9PVH_PoY0-RPflZRqKgUF_jSsNHLeoeAC2a5izGp_RQIFuh9gXldDI0OVpL4Si3Jcbz_ZJTroEfEYFonpRUS6K1Yuy8UNBuweud8o6g6wFF1q0vtC4BhVIZNxXMAatsKVut0Ii7JoDONvXEDRQNlpb9JZlw1Qdihpow9GAroZETg3Fy-o11DeErdGFxBYCAObg_NV284Cy323f9A7NwtRdi8oXNU-Jf5O9l4Ljcdy_zADXaMHgzgiHveEZwPUGOovcv3xb3SIIz0MXwtmzPmbvaXjGV2W8U70v_iKbR0-eRWytp6NA0JIHT8KBwRKVbyGu8lpp4_U4iDCwfNGK2Y5zVHIP-AfLzvXwvV1oC3rSD4BGfJ7wWTJjI5zHkzhJsiyN41Ezn0455zmL4jjNijihBU0mnHI-oTM6m03jkZjTiKZRGk9iGiU0GceIZY7JpKBpxbNpSdIIWybkWMrndqxNPRL-HMynsyiPRpIVKG349odShTsIk747zFYjMw_fqRRdbUkaSWGdPXlxwkmcn7OstINuy5nPlHfGt1R-IwA7yAyl1xmlsEIrr1rLTvye2B11Rs4__HVPwG0JXYe8_hMAAP__oJRcEg">