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

    <tr>
        <th>Summary</th>
        <td>
            [RISCV] Optimization Affected by mayRaiseFPException on FCVT_D_W[U] instructions
        </td>
    </tr>

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

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

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

<pre>
    Hi LLVM community,

There appears to be an issue with MachineLICM optimization caused by the mayRaiseFPException flag being set for the FCVT_D_W and FCVT_D_WU instructions in RISCVInstrInfoD.td.

[Here is a reproducible example on Godbolt](https://godbolt.org/z/GYa7GKrbP)
The fcvt.d.w instruction was hoisted out of the loop when compiled with llc-15, but it remains inside the loop when compiled with llc-trunc.

According to the riscv-isa-release-1929d45-2025-03-26, fcvt.d.w[u] computes the exact value when converting from a 32-bit integer to a 64-bit floating-point value. However, the spec does not explicitly state whether these instructions may or may not raise floating-point exceptions.

Here is the PR that originally introduced the mayRaiseFPException flag for these instructions:
[Previous PR](https://reviews.llvm.org/D115540)

I believe this flag was added based on the RISC-V ISA spec, but since the spec does not directly mention floating-point exceptions for these conversions, I would like to clarify whether the flag is truly necessary. For comparison, the fclass.s instruction is explicitly documented as not setting the floating-point exception flags.

Conclusion
The FCVT.D.W and FCVT.D.WU instructions may not need the mayRaiseFPException flag. However, I want to confirm whether removing this flag would result in any loss of information or if there are any corner cases where these instructions could indeed raise floating-point exceptions.
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyEVc1u2zgQfhr6MrAgUZYdH3xw7HVrbIsN0jaLngqKHFmzS5ECSdlRn35ByknTbnZzMAz9UN_PfDMjvKeTQdyw6pZV-5kYQmvdRpKTXwdhZrVV4-Y9wYcPDx9B2q4bDIWR8R3Ltyzffm7RIYi-R-E8BAs1gjBA3g8IFwotfBSyJYMfjruPYPtAHX0XgawBKQaPCuoRQovQifFekMfD3W-PEvv0RqPFCWokcwKPARrr0quH3cPnb_tvf4Iw6vniC5DxwQ0ynvRABu6Pn3YPx3jzaBq7z4LKJs6sun0fWZMHAQ57Z9UgqdYI-Ci6XiNYA--sqq0OrNozftOG0HtWbhk_MH44TY8y606MH74zfnj3Vaze_e7qO8bXkynQyHPIVHZ5SQsuwkNryQdUYIcAtkmCtLU9XFo00eCeNKrJOq3lvKgY30E9BKAADjtBSZ0nhW-eDW4w8ip6K6V1KloZbDroyMvznLyYO9QoPM6LNV-rRTXnOa_meTnnywj9JIRVtwOr9glmCOjTR_BRyABnoWO1JxLmjC5EnMbZDgSUfF5TADIBT-giuoDlIt1rtBXx1XlvyVw_k8F7e8EzuogdIXyPEpRFD8YGwMdek6SgR_BBhIQaWkzB8PhzBjoxgnXpLx51MV6_YuJT2PzVp6dkROi7ewitCGAdncgIrccoI8UF1f-n9prVXyjFCKX83Tk8kx083N2_lrD4FC8-0_rcXWO2L4qqWuRTwFi-PUKNmvAcU0B-Ao3xEkrFphKxtaxJJGMjzB_g-GmbzHzKkycj8RWLFTmU0eAOzVXQf1j2QuVUd59E8h0c4WIHrUDT3xhLLrVw1IwvqzVRjk67QY9gUKL3wo0ZHKxLKROOvDVPOWikFt5n_qeGIv8yEcrKIZJGBWLS4jGkLE54r8tIRJ7Kv7NG6iHquPZxnC_ZPvsxbOLFl38HLaIZfCMWP4X7CBdhQnLHmoZc9-yOw86eJ9rPpU12OvSDjr0EwoygrfdxhJBprOumoWodUBoqcSrHnxlBWmfQgRQefcRw-Fq3yIRARkURb_XKTG1KtS7XYoabYrUo80VeLNezdlMXUhS1VCtRLMX6ZlXyVdHwJd5UalHiajmjTRwveclXebFY83W2aG5wWct1vZDljSqRLfI45fRz-GdpmWyKsizWfKZFjdqnbcW5wcu0ahjncXm5TTw0r4eTZ4tckw8_emgWKOi05tJiiKPsj5fraNs0KMO0kF6rnzXPu4ZVt1_i-Zf-zQanN7_sCQrtUGfSdowfIo3r37x39i-UgfFDIu8ZP1zVnTf8nwAAAP__xwqiEA">