From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id D14E13858C52; Wed, 28 Feb 2024 09:51:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D14E13858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709113905;
	bh=od6ylASaAseneUU62lpm/nwYxsENft+vhDYyIbiW7bQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=gvko32vX5UQeC9ENOSEekPiECPQ/UsJJIz0nlF9vtPtEXwk8tpp5/oOj23yYaOLj3
	 aANiW7yLY9hQ1P0CmPnAf+2xuX1Ac6N19FKLa4q4/ThOTQNrCdHwEfD7pHHbt14D0J
	 hfxCRnzh620GReE7c8/020W6FRqHpc8Gqar2j2Fg=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/94083] inefficient soft-float x!=Inf code
Date: Wed, 28 Feb 2024 09:51:44 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-94083-4-g2ethqnBNp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94083-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94083-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94083

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Shall __builtin_isinf (x) or __builtin_isinf_sign (x) raise exception if x =
is a
sNaN?
Or never? Or it can but doesn't have to?
glibc's
        int64_t hx,lx;
        GET_LDOUBLE_WORDS64(hx,lx,x);
        lx |=3D (hx & 0x7fffffffffffffffLL) ^ 0x7fff000000000000LL;
        lx |=3D -lx;
        return ~(lx >> 63) & (hx >> 62);
doesn't, but I think when we lower __builtin_isinf to fabs (x) (which should
just clear the sign bit, not raise exception) u<=3D <max_representable_fini=
te>,
it would.
If we wouldn't need to raise exception, I think fastest would be to pattern
recognize the fabs (x) <=3D <max_representable> and emit there the (lx | ((=
hx &
0x7fffffffffffffffLL) ^ 0x7fff000000000000LL)) !=3D 0.
But __builtin_islessequal (__builtin_fabsf128 (x), __builtin_nextafterf128
(__builtin_inff128 (), 0.0f128)) I think should raise exception and those 2
will be indistinguishable, so maybe just recognize that case during expansi=
on
if 2 libcalls would be needed and emit the equality comparison instead.
Or do both depending on if -fsignaling-nans is specified or not?=