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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
