[cfe-dev] [llvm-dev] Do we need intrinsics for floating-point classification functions?

[Sanjay Patel via cfe-dev]

On Thu, Sep 2, 2021 at 4:00 PM James Y Knight <jyknight at google.com> wrote:

>
>
> On Thu, Sep 2, 2021 at 3:07 PM Sanjay Patel via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Thu, Sep 2, 2021 at 2:34 PM Serge Pavlov <sepavloff at gmail.com> wrote:
>>
>>> Optimization is not the motivation for this intrinsic. If FP exceptions
>>> are ignored, unordered comparison can be used to implement `isnan`. If not,
>>> we need to make the test without affecting FP exceptions. Without this
>>> intrinsic there is no way to represent such a test.
>>>
>>
>> Here's a way to represent such a test without an intrinsic:
>> declare i1 @isnan(double)
>> ...
>> %r = call i1 isnan(double x) #1
>> ...
>> attributes #1 = { nounwind }
>>
>
> No -- there is no "isnan" standard library call. C "isnan" is a macro
> which expands to whatever each libc desires. There is effectively no
> standardization as to what library function -- if any -- they actually end
> up calling. Therefore, the compiler's __builtin_isnan (and friends) cannot
> reasonably rely on generating library calls for these.
>

Hmm...so the Apple clang "@__isnan" is a hack that we can't use? It seems
to be there specifically for the FMF-based reason that was mentioned
earlier as motivation for intrinsic isnan. Ie, it only seems to appear when
'nnan' would otherwise zap the corresponding 'fcmp uno'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210902/0a30c814/attachment-0001.html>