James Y Knight via llvm-dev
2021-Sep-02 20:00 UTC
[llvm-dev] [cfe-dev] Do we need intrinsics for floating-point classification functions?
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. Probably the best you could say is that we don't support __builtin_isnan/etc in strict-fp mode. But that's not a good solution, either. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210902/b1da59cc/attachment.html>
Sanjay Patel via llvm-dev
2021-Sep-02 21:48 UTC
[llvm-dev] [cfe-dev] Do we need intrinsics for floating-point classification functions?
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/llvm-dev/attachments/20210902/0a30c814/attachment.html>