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

    <tr>
        <th>Summary</th>
        <td>
            [SelectionDAGISel] Mysteriously dropped chain on strict FP node.
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            llvm:codegen
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            uweigand,
            nemanjai,
            topperc,
            efriedma-quic
      </td>
    </tr>

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

<pre>
    [testcase.tar.gz](https://github.com/llvm/llvm-project/files/8372375/testcase.tar.gz)

llc -mtriple=s390x-linux-gnu -mcpu=z15  ./tc_fpc.ll -o out.s -debug-only=isel

I started looking into the missing modelling of the Floating Point Control register on Calls (inspired by https://reviews.llvm.org/D111433, for PowerPC), and found to my surprise a particular opcode where the generated pattern matching does not preserve the chaining on the strict FP node.

More specifically, the first function in the attached test case makes two calls to @llvm.experimental.constrained.rint.v2f64(), separated by a call. Even without the (currently) missing FPC dependency on that call the chain dependencies should cause two separate VFIDB instructions ("VECTOR LOAD FP INTEGER") to be emitted, I believe. As seen in the debug output however, the chain is simply dropped:

```
ISEL: Starting selection on root node: t14: v2f64,ch = strict_frint nofpexcept t13, t2
ISEL: Starting pattern match
  Initial Opcode index to 42631
  TypeSwitch[v2f64] from 42633 to 42744
  Created node: t25: v2f64 = VFIDB nofpexcept t2, TargetConstant:i32<0>, TargetConstant:i32<0>
ISEL: Match complete!
```
The emitted MBB therefore has only one (reused) VFIDB, which is wrong as a called is crossed which may have changed the FPC setting.

If the type is changed from v2f64 to double, the chain is *not* dropped:

```
ISEL: Starting selection on root node: t12: f64,ch = strict_frint nofpexcept t11, t2
ISEL: Starting pattern match
  Initial Opcode index to 42631
  TypeSwitch[f64] from 42633 to 42636
  Morphed node: t12: f64,ch = WFIDB nofpexcept t2, TargetConstant:i32<0>, TargetConstant:i32<0>, t11
ISEL: Match complete!
```
The resulting MBB has one WFIDB before the call, and one after, which seems correct.

The patterns for VFIDB and WFIDB are both defined by the same VectorRounding multiclass, so it is strange that there is this difference. It is also worrisome: how can this happen without any assertion triggering? Is there any case where a chain is actually correct to drop, or could we add an assertion for this?

I see a comment in PPCInstrVSX.td "Rounding without exceptions (nearbyint). Due to strange tblgen behaviour, these need to be defined after the any_frint versions so ISEL will correctly add the chain to the strict versions.". Maybe this is related...?

And I see some 
`"OPC_MorphNodeTo1, TARGET_VAL(SystemZ::WFIDB), 0|OPFL_Chain" `
in SystemZGenDAGISel.inc, but only 
`"OPC_MorphNodeTo1, TARGET_VAL(SystemZ::VFIDB), 0"`
(no OPFL_Chain) for VFIDB.

(The following two functions in the test case are very similar except strict_fp_to_sint is used instead, which seem to be correctly handled).

</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy9V9tu4zYQ_Rr5hYhgS77ED3lw7CRwsdsYmyBb9CWgJMpiS5EqScXxfn3PUJKdBFv0graAIVsyOTxz5sxFmSmOV9Hs2gvnc-5E7LmN99-i2SZKLivvGxelqyi5xWcvfdVmcW5q3Cj1MnxdNNb8InKP21Iq4fB9mS6SdDHDr492k2U03kTjVXdVKmcXtbeyUSJKNy5djl8vlNTt68Vet_grb1o8_zaZMRaTtfy5bPJYKXZhmGl97NhFIbJ2f2G0OmKldEK9PWDLHA72omDKmF-l3jOpvWG-EqyWztGD2hRCKfplyvDHrTLc0_3OYDFbG-2tUcyKvXReWGY0W3OlHANDUrtGWpjPjuw9W1a8SHFwMTEUG7vHo81kMpmmaZSsWWkszB-E3a2JEjzhusDTFlfgq4_MtbaxcIdx1sADmbeK4-wmB1x2qIQVAexeaGE5OdhwD3Sa1dznFcEvjHBMG88aK5ywL92GvOJSB291uHdgP_fsdoelhYjfkvfZ4BDXiFyWMofHR8JJe0ppnWdlq3MvYUZ2lnA-zysgoZgzCjqw_AoM_mBYHhiDa9F0HCgRr42wshbacwVNaeAAMFHEFqTHL0k5n4LfnhwnwEHwEjzzYCxmNy9CswNECSEEAFift9bCJEFdniJ8u1uzQjRCF0Lnx85x7oOVMyXnFRKQHYyqAktaeEH4BwTs6Xa7uYbLwNsG94MOoiR5ulk_3n9hn-5XG2Jz--Pjzd3NF_xBUOB4JpioJWJUkEdb3CspXkTMVjhOiBONQc8k7gZuVdDIi7AD8R1SiQ2ybtSRFdY0DQymq7dxi-bj_tPlwMPNJ6xgD5QJxAdyRHSRw8caKIRCT0v8ZEpfPfvrvGLIqV4izyVFBkvLRrzmogHnk6Bln_zBOe8U2a1hbKull1yx-07JEpS_Ej3TZJ5OhkWPx0Y8ILTYNrvu0Mw2rLSmDuvSbsNiOh02rK0I8jg5ksxOjgQfurC9BZ8Q9kdu98KvSX5ce2yRaRKl63GU3vzZ3-98_kwuMpRGFDIvomTy3Ug8VicNsM_X1xRSK0rKsoo7RiUMl6BjKyC8gpQTgBOWQyVxBGJ_sAbkYkOXCLCFh7k1Djv6VTVHOeIvQTB6TylJdW1HieQpNO_SfNuVPQ_Og6V-S2C7IxBsF6bNUKM_6jBKVqgwuP4HUkzo6y8KcfJ_CPEPZDhP58NyVMymeivD7zjx9V9XIrk-mfxTQaI5tCrQRJLshCh6lFmnzhBySG3oU7SAl76rS53iUMFqaMeg_Ob-nbzojD4ALvS9LhXJTncIxwmZ8RUqX0kdgGp86Ey8RrmFOWO_UGMMzZqg5oo7F9qCYdKHcojmAdF2dT1kFT31FS6FLEvc6xyVdhsWc4V9ByCVztQhTKiy8E93GyoOHZ8bC9foOEgtG1QKAe736Ft6H6W3bOv6w2hRaHhdY-bnBOG5b6l1DtSEXEKqEHxwkYc2c8CWooCVNycRU4QH53wYaEQ4wNTUO6lp7HbrLbWjp4efYl8gJZMTXYMTndKGZqUFt9kROYT6ErNNKwjUicJMYaZA5FE_pGmH1gPftBBF38iGSAURdM1fH_u8RLty4SSwTGoECPTZ3n0QQZ6ea0g_jPVTyLAXs14SQ8PHTHRBwccKRSU-juMPlKygpI4Wiic7Cz1J7nfr55CTPyIhH02oEo-rL3c3j89Pq0-g4uGIka7-mapWuvraldowcYyjxfp-d_vpeU0wYYqdkgao-213Qm9Wd9sHoWKpc9qWgexQx_85iqd3KDA-DOdS5Ax7C2p5zqd3KYeVlHWlUcocSAc0wQzjmhsGjfOYRhkI6o80VkgaM_vKNNTb5tmbZ0fBRRyoMYX5R_Diff734jiHGp2kUKGN9fBGxVVaLNMlH3nplaAXj4ehA_RMUoX9THxYqM-dZ5xeL8iMDxPrqLXq6m-_qWA0bMOrymw6nyxG1RVfzJPLxSXnxXiZLMfZbDxNF5M8E2mW5YvL-UhxTGyOICMowWi6os6BbKEozTYjeZWMk2ScJsvJbLxIL-M0WfApHmST6TydXS4x-4qaS3V6KRjZq4ALE5-jwRgvGOc3hhGKgdwj6_oz24OQezAaRso15bmGNf0Ll-cnnriy-fmBQFKKouYXv7Uy73HyFlXBXv1g9M45o0eBi6tAxO8O9o5N">