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

[James Y Knight via llvm-dev]

On Thu, Sep 2, 2021 at 5:48 PM Sanjay Patel <spatel at rotateright.com> wrote:

>
>
> 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'.
>

I wouldn't say a "hack" -- it's just an implementation choice that Apple's
libc made. The libc math.h can certainly implement "#define isnan(x)" in a
way other than "__builtin_isnan(x)" if it wishes to.

I just think it's not reasonable for Clang to try to figure out what
private implementation functions may be used by the macro-expansion of the
"isnan" macro in every libc, in order to have __builtin_isnan expand to a
call to that private function. Either we should expand __builtin_isnan
directly, or not provide __builtin_isnan. (And the former seems like a
better answer to me.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210902/2a96cf98/attachment.html>