[all-commits] [llvm/llvm-project] 4e8c14: [ExpandIRInsts] Fix e.g. fptoui.sat.f32.i256's han...

Justin Lebar via All-commits all-commits at lists.llvm.org
Fri May 29 12:39:03 PDT 2026


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4e8c14df16a7758ce5f471cfed200ad0e02847a0
      https://github.com/llvm/llvm-project/commit/4e8c14df16a7758ce5f471cfed200ad0e02847a0
  Author: Justin Lebar <justin.lebar at gmail.com>
  Date:   2026-05-29 (Fri, 29 May 2026)

  Changed paths:
    M llvm/lib/CodeGen/ExpandIRInsts.cpp
    M llvm/test/CodeGen/AArch64/fcvt-i256.ll
    M llvm/test/Transforms/ExpandIRInsts/X86/expand-large-fp-convert-fpto-sat-vector.ll

  Log Message:
  -----------
  [ExpandIRInsts] Fix e.g. fptoui.sat.f32.i256's handling of inf (#200261)

When expanding fptoui.sat/fptosi.sat, we saturate when the biased
exponent is at least ExponentBias + BitWidth - IsSigned, the point where
the value no longer fits in the target integer.

We should *also* always saturate when the floating-point value is
+/-inf.  Usually this doesn't require any special handling; for example
for a float32 -> int32 conversion, inf has a biased exponent of 255 >
ExponentBias + BitWidth - IsSigned = 127 + 32 - 1.

But for integer types which are large enough to contain all source
floating-point values, this doesn't work. For example, if you're
converting float32 to int256, you'd compute a threshold of 383, which is
greater than 255.  Therefore float32(inf) would not correctly saturate
to INT256_MAX.

Fix this by clamping the threshold to the all-ones biased exponent.

This bug was found by a large run of Opus 4.7 looking for bugs in LLVM.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list