From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id A0FC33857C4B for ; Mon, 15 Aug 2022 12:07:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A0FC33857C4B Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id CE6343717E; Mon, 15 Aug 2022 12:07:38 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C311C2C1C5; Mon, 15 Aug 2022 12:07:38 +0000 (UTC) Date: Mon, 15 Aug 2022 12:07:38 +0000 (UTC) From: Richard Biener To: Jakub Jelinek cc: "Joseph S. Myers" , Jeff Law , gcc-patches@gcc.gnu.org, FX Subject: Re: [PATCH] Implement __builtin_issignaling In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, LOTS_OF_MONEY, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2022 12:07:44 -0000 On Mon, 15 Aug 2022, Jakub Jelinek wrote: > On Mon, Aug 15, 2022 at 11:24:14AM +0000, Richard Biener wrote: > > Unlike the issignalling macro from glibc the builtin will return > > false for sNaN arguments when -fno-signalling-nans is used (similar > > to isinf, isnan, etc.). I think this deserves mentioning in the > > documentation (and I have my reservations about this long-time > > behavior of FP classification builtins we have). > > I have actually tried to make the builtin working even with > -fno-signaling-nans (i.e. the default). > That is why the folding is done only if the argument is REAL_CST > or if !tree_expr_maybe_nan_p (arg). > At one point I was doing the folding when > tree_expr_signaling_nan_p (arg) (to true) or > !tree_expr_maybe_signaling_nan_p (arg) (to false) and in that > case indeed -fsignaling-nans was a requirement. > -fsignaling-nans is used in the tests nevertheless because the > tests really do care about sNaNs, so I've turned on the option > that says they should be honored. Ah, I misread +static rtx +expand_builtin_issignaling (tree exp, rtx target) +{ + if (!validate_arglist (exp, REAL_TYPE, VOID_TYPE)) + return NULL_RTX; + + tree arg = CALL_EXPR_ARG (exp, 0); + scalar_float_mode fmode = SCALAR_FLOAT_TYPE_MODE (TREE_TYPE (arg)); + const struct real_format *fmt = REAL_MODE_FORMAT (fmode); + + /* Expand the argument yielding a RTX expression. */ + rtx temp = expand_normal (arg); + + /* If mode doesn't support NaN, always return 0. */ + if (!HONOR_NANS (fmode)) + { + emit_move_insn (target, const0_rtx); + return target; which doesn't use HONOR_SNANS but still HONOR_NANS and thus -ffinite-math-only. You possibly want MODE_HAS_NANS instead here? > > Generally it looks OK - what does it do to size optimized code? > > The problem is that except for the glibc __issignaling{f,,l,f128} > entrypoints, other C libraries don't implement it, so there is nothing to > fallback to (unless we want to also implement it in libgcc.a). > > For float/double, it is relatively short: > movd %xmm0, %eax > xorl $4194304, %eax > andl $2147483647, %eax > cmpl $2143289344, %eax > seta %al > movzbl %al, %eax > which e.g. for if (__builtin_issignaling (arg)) could be even simplified > further by just doing ja or jna, resp. > movabsq $9221120237041090560, %rdx > movq %xmm0, %rax > btcq $51, %rax > btrq $63, %rax > cmpq %rax, %rdx > setb %al > movzbl %al, %eax > For long double (especially Intel) / _Float128 it is larger (26 insns for XFmode, > 15 for _Float128), sure. > > > glibc 2.31 seems to silently accept > > > > #include > > > > int foo(_Complex double x) > > { > > return issignaling (x); > > } > > That seems like a glibc bug/weird feature in the __MATH_TG macro > or _Generic. > When compiled with C++ it is rejected. So what about __builtin_issignaling then? Do we want to silently ignore errors there? Richard.