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

    <tr>
        <th>Summary</th>
        <td>
            Behavior of overflowing floating-point to integer conversions
        </td>
    </tr>

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

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

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

<pre>
    This issue is either:

a) a missed optimization in the x86-64 backend; or  
b) a wrong optimization in the aarch64 backend.

Consider the following code:

```c
#include<stdint.h>
#include<stdbool.h>
bool is_i8(double x) {
    return x == (int8_t) x;
}
bool is_i32(double x) {
    return x == (int32_t)x;
}
```

As per the C standard, these functions invoke undefined behavior if given arguments that, rounded to an integer, don't fit in the desired type. Thus, `is_i8` can always be replaced with `is_i32` ([alive2 proof](https://alive2.llvm.org/ce/z/TokdT9) from the optimized IR).

However, the x86-64 backend does not do this, and thus `is_i8` has an unnecessary `movsx eax, al` instruction that can be eliminated. The aarch64 backend does do this optimization. [compiler explorer](https://godbolt.org/z/Kj5hEjcq5).

GCC preserves the int8_t cast on both x86-64 and ARM64 (and everything else I tested in CE): https://godbolt.org/z/78MbdGbPz.

And while C does allow the optimization in question, it means that `x == (T)x` cannot be used as a check for whether the floating-point value `x` fits in the integer type `T` (even though it would work if the conversion gave any valid value of `T` in place of UB/poison). And, as far as I can tell, there is no alternative way to do a check like this anywhere near as performantly, without writing platform-specific assembly, which is, IMO, a quite problematic issue, though not really a clang-specific one.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVdtu4zgM_RrlhWjgyrk-5KGXyWyxGOxi0H0eyBIdcyqLHklOmn79grZ7nQKLBYomjkj68PAcyqREh4C4U8trtbydmT43HHfuyVBrZhW78-6-oQSUUo9ACZByg1GVV6q4VcX03yi9BQMtpYQOuMvU0pPJxAEoQG4QHjeri9UCKmMfMDhVXgNHgDG7GrNPkcPh02Rjom1es-dvX33DIZHDOATW7D2fKBzAssMPINWqGP_s9KxLCtb3EniTsqOQ540qv3x-WjH7N8fyCJR-0EbpjeO-8giP0odaX48RAAARcx8DPIIqb1V5C0pvKOTNjyyRj6qcQtX69kPVUv__sqUe6n5S9qXzt3RcJegm2m4gZROciU7pG_klIdR9sDKDBBSO_IDQB4c1BXRQYWOOxBGohgMdMYCJh77FkBPkxmQpElniHWQGI3PMeMAoB46D0usMNeXn8TpMFCX23OEc7ps-SaBaFSO_qwKsCWD8yZwTVAgRO28sOjhRbp7jSi2BSm_U8tp4OqKGLjLXanmr9KbJuUuiB71Xej-ez70_tnOOB6X3FpXePym9v-cHd78VxuvI7QBvUiQ6uPuu9Pad-v7gEx7Hxn5XOTjGBIEzOIbc0NCWCQ5y06d3_TUmCU19CGgxJRPPctzyMT0Cmschz0sghZRjPwxmoHpgpkJATy0Fk9EJgb85ZkQyoXhnsTmo5bXltiOPEfCx8xwxfkbagV3FPk-ECVd__lw2X37aX8uPrHy9uYEuYsJ4xDQQM6oerEkZOEDFuXkmSwi5-v5ttZDhyYMQes6NuBh9QriDjCmjE7ncfFF6q8or-C9s6823yn2t_n56B-wqODg15EXyAyVG9sXbKb_snV89Jvku3FOGFk0Y1S2Teeu8-8Fzo0hl1hVCL1tQRgq2QfsANUc4NSiLc1xTnk2mcLjomEKGo_E9DmWlTE05PTtj8s3gDAm4nzSOYrrccH9oBNyJe-_gxPFBLCmJlsMRY5JeDuaIYMJZXkNuehnXL-UowGAn-e2fa6X3HVOSvrdzuArDRjAJahPl424QXEbvJ8nH4VIIDMZnjMFkOiKczFmM7_iFAU8POIrPhPNpSAs4luww1hxbE7I_S1ExNfcZTpGEIwGXJeAidWipJgsmJWyrKboh28Borbtvfw1o4VdPGcX-lcfWZLLj9TVCHkiTQUU03p8Fojfh8FqeA85nble6bbk1M9xdrraL7aZcFMtZs1sv9cqahb20rrgs1mvrVtbgalHU1mwKXcxopwtdFtvLtS4WpV7Oi3JRuVIXl67StbYLtSiwNeRf1s9sALdbrVZFOfOmQp-G21jrgKdn5Fou57iTnIuqPyS1KDylnF6rZMoed9fPu5lr4CPGeroPP0gu84u2XqWSZn30uw_Ootz01dxyq_Re3jV9XHSRf6LNSu8HhEnp_dDBvwEAAP__NiCvag">