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

    <tr>
        <th>Summary</th>
        <td>
            [mlir][spirv] Support fast math mode during conversion
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            mlir:spirv
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            antiagainst,
            kuhar
      </td>
    </tr>

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

<pre>
    SPIR-V itself is just a general GPU IR encoding format that provides basic semantics to various ops. The final semantics of each op are defined in the client API, esp. regarding floating point numeric behaviors. E.g., [for Vulkan the default](https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap46.html#spirvenv-precision-operation) is to expect denorms can be flushed and no NaN as inputs. While [for OpenCL that's not the case](https://registry.khronos.org/OpenCL/specs/2.2/html/OpenCL_Env.html#_inf_nan_and_denormalized_numbers). WebGPU right now assumes backends can perform fast math optimizations so no NaN as inputs too; actually [not even ways to check](https://github.com/gpuweb/gpuweb/issues/2270) whether a number is NaN.

In order to serve these differences, we need to tighten the handling around special floating point numbers. Specifically a list of tasks:

- [ ] Introduce an option, `enableFastMath`, to `SPIRVTypeConverter::Options` to allow turning on conversion assuming fast math.
- [ ] Emit `SignedZeroInfNanPreserve` if not in fast math mode.
- [ ] Audit various GLSL extended instruction set ops to make sure we generate proper `spv.IsNan` guards for inputs if the op itself is undefined if inputs are NaNs (e.g., FMin/FMax) and not in fast math mode. Don't need such guards if in fast math mode.
- [ ] Similarly for various OpenCL extended instruction set ops.
- [ ] Check to make sure arith ops semantics are properly respected when converting down to SPIR-V ops. (e.g., right now arith.minf/maxf is not properly handled w.r.t. NaN behavior.)
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyVVV1v2zgQ_DXyCxHBkfz54AfnqzCQtEHTywH3YlDSymJNkwJJ2Ul__c1S9tnXFD0cYFuytNqdnZ0dFbZ6X7w8r75evQoVPOlaKC--dz4IKTZkyEktPj3_IVZfBZnSVspsRG3dTgYRGvy0zu5VRV4U0qtSeNpJE1TpRbBiL52ynRe29an41pColUG6c4ytBcmyQYCQjkRFCKBKKIPcJEqtyASxfF4l2a0g36bC0Ua6HoO2MvBJaxWCTLcjh_oFNXKvrEPB-3ST8oPJ-AaAxWunt7JPjDqy0yEZ3yXZrAmh9Um-TLIHfFBA-eDe023jrLE-tW6Dy_v4ME58S6XH8TrNr-gtkPHKGr7QhJ3GoWxkO5qk_b_ct8rtyeyvWkel4tAr24LSgLMkmzPVoInekDQAlQGvXpRAWYAr3fkGZEhTCWPFZ_lZSA9q2i6guT8bpenU2peWzO1jnEeSTT3CQ0-g9PQ_muzTXDSZpdm5s_7u-t7sT92tlanXRpo1IK579FKrH1StMY2CHFLMgZQK1o9TmwZjsgd04TEsFky5JVP1DYMVVpWoJZQHcbEmgtqpH5ErL7z9QAKos0l-I2QZOqn1O7PBnRMYFwf5HrktGyq3v-Jgo0LTFWlpd_yn7Q5UXJ4ogKTIQTYd8qgODYFSh63om-PZAU6aDO-S4bL_XRlhXYV7KOwJk-cpeOhN1TU5rA9nvBUHEoYwWUQFZoV6VTagUbOipbMdhs5TUFiXj0pnblPxwvdrVcbepdAYKS9UkH4b27wAdsXc4HsnViY4W3UlQVeRYhYidmQyJCMLTQ_g_wn04wJfB0ScsT-8fntv6daaPblAjvPnyy_xeY8IDgQOTDd0zjBYa0QZo1n1_czj2p7mm_6M7H6nQiymNvCAv8jZlak_S_PsKHLJVVQdtQ1_OOtkZyv6kGzZVch28p9Pjy-PIm5rFd0F2u9Kho4pBXYnhr-TWxK-gw1hPr3zBWJ7gzQZl2_36coDEAPZdLAhz0Z4EiOg8RDhZGcbxRRPjlaf4tjnoBsvoEg6OtTDk2JveXiSbyy1fuN_1aa443FNQ68f38E6j0higf9i5QULpaWDXBj4iZ2je_yOnw-Zbnmt_s0assWt9Rf-zs32DKIm5sg-hwrYpZM6orArezCc7Pgeiq-LC3ourINrpBBSDbp28i2yzFT9UyQuEZdIXRrSaBinVwJyzQe0uJ5MstFsPB-PB9Uir-b5XA6CCpoWaG6nlWO3GN9E646kdW1rXfiJW1F1jqGfNT7onF78xmO03p8OeB3Y76Di0mfG0_FsNGgW03E5HcqizPOympTzYS1HQzkrRjSj6XSUVwMtC9KewSZZFvHmyx5slgHvQC2yYZYN58PJ9TSfX4_TCfJU0_l1NqnryWw-SkZDDEjplKGw9Q_cIqIquo3HTTYSf76J1eWNpGNFnqzcSBYJF2TvyLJt10h3rC-70Fi3uIgbxCYXscO_ASld3Gc">