[libclc] [libclc] Fix int<->float conversion builtins (PR #126905)

Fraser Cormack via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 13 03:26:07 PST 2025


frasercrmck wrote:

> Do we really need to generate source for this? It's harder to reason about. It looks like the sign bit of the input isn't preserved on underflow to 0

Perhaps we could simply check in the generated source? It shouldn't change all that often. We might want to split it up into separate files as it's massive.

This sort of thing should really be in an issue ticket, but I had a brief look at the remaining failures yesterday. For some context:

``` c
_CLC_DEF _CLC_OVERLOAD half __clc_convert_half_rtp(float x) {
  half r = __clc_convert_half(x);
  float y = __clc_convert_float(r);
  half sel = __clc_select(r, __clc_nextafter(r, (half)INFINITY), __clc_convert_short(y < x));
  return sel;
}
```

At least it's nice and small.

Since the first two conversions are just `fptrunc` (`0xBE60000020000000` > `0xH8001`) and `fpext` (`0xH8001` -> `0xBE70000000000000`), and `y < x` should be true, it seems we expect `nextafter` to take us from from `-0x1p-24` (`0xH8001`) to `-0x0p+0` (`0x8000`). This makes sense to me, but it takes us to `0xH0000` instead.

I do pass the OpenCL-CTS for nextafter in the same (admittedly janky) configuration so I may have crossed some wires somewhere.

Anyway, I ran the full OpenCL-CTS with this PR overnight and the only remaining failures are those six I listed above.

https://github.com/llvm/llvm-project/pull/126905


More information about the cfe-commits mailing list