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

    <tr>
        <th>Summary</th>
        <td>
            LLVM lowers consecutive `half` operations with too much precision on several backends
        </td>
    </tr>

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

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

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

<pre>
    Consider the following IR:
```llvm
define half @f(half %a, half %b, half %c) {
    %d = fadd half %a, %b
    %e = fadd half %d, %c
    ret half %e
}
```

On backends without native `half` support, LLVM generally lowers `half` by converting to `float`, performing the desired operation, and then converting back to `half`. For this to be a valid lowering, a conversion back to `f16` must occur after each operation, otherwise the excess precision of `float` will affect the result. For example `65504.0 + 65504.0 + -65504.0` equals infinity if each operation is done at `half` precision, but will result in `65504.0` if the intermediate value is not rounded to a `half` but instead kept as a `float`. This excess runtime precision can lead to miscompilations similar to #89885.

However, it appears that on several backends LLVM will fail to round the intermediate result of consecutive `half` operations, leading to these kind of bugs. I'm filing this as a single issue rather than a separate issue for each backend as I believe this is an issue with LLVM's default handling of `half` operations rather than a problem in any specific backend (for instance, AFAIK the only backend-specific code LoongArch has for handling `half` was added in #94456).

By inspecting the assembly LLVM emits, I've discovered that at least the following backends appear to be affected (in brackets are a specific target triple that I've checked):

- AVR (`avr-unknown-unknown`)
- Hexagon (`hexagon-unknown-linux-musl`)
- LoongArch (`loongarch64-unknown-linux-gnu`)
- M68k (`m68k-unknown-linux-gnu`)
- MIPS (`mips64el-unknown-linux-gnuabi64`)
- MSP430 (`msp430-none-elf`)
- PowerPC (`powerpc64le-unknown-linux-gnu`)
- SPARC (`sparc64-unknown-linux-gnu`)
- WASM (`wasm32-unknown-wasi`): Already reported in #96437

I also noticed that 32-bit ARM has this problem in LLVM 18 but not on the `main` branch. Looking through the issue tracker, it seems it's likely that this was fixed by #80440.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyEVlFv8joP_jXlxgKVtBS44IJtmt7pe6dv2o7ec-2mLs0hTXqSFMa_P3JaWLddTEJAGtt5bD9-GvReHQzRLlndJauHGfahsW5XEgVH5GelrS67e2u8qshBaAhqq7U9K3OAp9ck2yfpQ5LukyIdPlqf2uFRRbUyBA3qGpI8rROxGf6LFSbiHq6LcrqQidhCsr4bQgAAP6wgyR6gxqqCTxGi89SQvhtWo6H8MHQUbts0wl8_fMljXMbv_xsoUR7JVB7OKjS2D2AwqBNBUqQcKilS8H3XWRf4vN-__zzDgQw51PoC2p7J-alteQFpzYlc4DoGy3u1thj4ZHEPHbnaujZuNgQVeeWoAtuRw6CsYRs0FW-aaSSGOYYbj1rAo-W-Kc_PSwKEE2pVDaCUOcRQYwyvrJnGqJcFo217H8BK2TvAOpADQtl8BmNDQ-6sPEW89C7Je-gcSRVj2nqaIZyV1oB1TTJEe0e-12GASu_YdjpWtlit0nyRQiLuYPp_Pi44FP3bo_agTK2MChdQ9Rd0oDxU1hBgmHbgho3Rl30YMA1AQJnJ8Wyt6ohTmUCupUphIC5jTxzd2ADO9qaiiuuGnxrdczQfCCs4UhcA_WBwrcUC_uLejBVzvQmqpUnlJBrQ7B0stMpL23ZKx8Q8eNUqjS42S2Sb7WazWkx5-8ue6USOM1QBsOsInYfQYABrwPMe6g9qR9bGMtSoNEeNWX3PfKySrZk2nmT_dRRuxfd8NsMfaR4a8gRHZSr2LvuDX8BTItYt1EoPbFd-qJFX5qC5vr4ncMj8YuiGt6hDx0CGzdqOjBwzYf8nKEkrOtEQkYOa0ZwnOOaaiLWHimrkZBo0VUQwUPV7Jl8wdM6WmlqmCpoL-I6kqpW8YUjEhnFx79FI4jrsH_dP_4vVtEZfrpbzm6u0FcFva81h72QDDfqY2g3ZBNaZS1Qx4ZiqItvm-apIxPZT--8ufHxHMlx1BL2nttSXodXUqhAbxB04EVRMrxOx0ESOYODW-fBF9W98GQh1lZU4zRQTVwZKx1bBAzqWnFuOAd2BAgSneMbjMePpsiF5pCoR24-XSvyew_7PK4dNihRPbt6bo7Fnc_2Nirm9mv6idzxYM5o3w-rmopXp3-dt7_Vnr4-iD36a1-hkU-RffA-m_-z6XGyOo1dbbI4_mj-9vF3NVeeLnPR3FyxVkX_xe3vJs_Tq6bs8S-fGGppTJMTE8oV1_eV-NO141cki1_QTtLeX_evVzXfo5M_J_71_ex49zujbTNwczujVaJvtYa8dYXUBR_yG_GBtkWfraaufALW3LKhKXlmYiXmpAuxfn-NExHGeDF9k8nIThZaF2JpIV64SKhMl2KGRzYKbfBwGwdn-0AyyFhUhRLJeddITtR5UiPKg1ZH0ZUASj-bJq9U7VfwOZ9VN8zxdzKpdVm2zLc5ot1yLNNsui9Vy1uwyuZJlvSYUmw1hKVAQbsuNWG6xrNMSZ2onUpGn63QtRJYvlwtRpKus3lTrclsKKrMkT6lFpRd8s1pYd5hF0LvtertezTSWpH28vAlh6DxklAjBdzm3Y585y2ySp1r54D-iBBU07WL5xvvJj2I-SGewFtpeNtPX-_e3yax3eteE0HkeZ_GYiMeDCk1fLqRtE_EY74nDz7xz9h-SIRGPEb1PxOOQ3Wkn_gsAAP__w5FtQg">