Bug 30652 - SSE expansion is missing for isinf() and other fpclassify functions
SSE expansion is missing for isinf() and other fpclassify functions
Status: WAITING
Product: gcc
Classification: Unclassified
Component: target
4.3.0
: P3 enhancement
: ---
Assigned To: Not yet assigned to anyone
: ssemmx
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 12:39 UTC by Uroš Bizjak
Modified: 2009-11-22 17:58 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2007-01-31 12:57:28


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Uroš Bizjak 2007-01-31 12:39:18 UTC
Following testcase does not compile to inlined asm when -mfpmath=sse is used:

--cut here--
int test(double a)
{
        return isinf(a + 2.0);
}
--cut here--

gcc -O2 -msse3 -mfpmath=sse -fomit-frame-pointer:

test:
        movsd   .LC0, %xmm0
        addsd   4(%esp), %xmm0
        movsd   %xmm0, 4(%esp)
        jmp     isinf

An "isinf<mode>2" expander in config/i386/i386.md should be enhanced to expand isinf() function to use SSE1/SSE2 FP bitops for -mfmpath=sse.
Comment 1 Richard Biener 2007-01-31 12:57:28 UTC
Confirmed.
Comment 2 Richard Henderson 2007-02-01 00:28:23 UTC
The generic implementation, including for SSE, is 

  isgreater (abs(f), FLT_MAX)

For isfinite, use islessequal instead.  For isnan, one can use 

  isunordered(f, f)

For isnormal, it'd be

  isgreaterequal(abs(f), FLT_MIN) & islessequal(abs(f), FLT_MAX)

which is less likely to be friendly to inline.
Comment 3 Uroš Bizjak 2007-02-01 08:16:32 UTC
(In reply to comment #2)
> The generic implementation, including for SSE, is 

I don't think we want to be too generic there. We should not implement proposed transformations as part of fold_builtin_classify() [builtins.c] as this would penalize soft-float targets too much. In this case, we would trade one call to isinf() to calls to __unorddf2 and__ledf2 plus fabs() bit-manipulation. For isnan(), we trade the call to isnan to the call to __unorddf2.

IMO, we still need optabs here...
Comment 4 Kaveh Ghazi 2007-06-13 15:57:20 UTC
(In reply to comment #2)
> The generic implementation, including for SSE, is 
>   isgreater (abs(f), FLT_MAX)
> For isfinite, use islessequal instead.  For isnan, one can use 
>   isunordered(f, f)
> For isnormal, it'd be
>   isgreaterequal(abs(f), FLT_MIN) & islessequal(abs(f), FLT_MAX)
> which is less likely to be friendly to inline.

I'd like to do this, but how does one generate FLT_MAX et al. from the middle-end?
Comment 5 Kaveh Ghazi 2007-06-16 03:44:12 UTC
(In reply to comment #2)
> The generic implementation, including for SSE, is 
>   isgreater (abs(f), FLT_MAX)
> For isfinite, use islessequal instead.  For isnan, one can use 
>   isunordered(f, f)
> For isnormal, it'd be
>   isgreaterequal(abs(f), FLT_MIN) & islessequal(abs(f), FLT_MAX)
> which is less likely to be friendly to inline.

Generic isinf implementation here:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01103.html
Comment 6 Kaveh Ghazi 2007-07-18 17:30:50 UTC
Subject: Bug 30652

Author: ghazi
Date: Wed Jul 18 17:30:38 2007
New Revision: 126724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126724
Log:
	PR target/30652
	PR middle-end/20558

	* builtins.c (expand_builtin_interclass_mathfn): Provide a
	generic fallback for isinf.
	* c-cppbuiltin.c (builtin_define_float_constants): Move FP max
	calculation code ...
	* real.c (get_max_float): ... to here.
	* real.h (get_max_float): New.

testsuite:
	* gcc.dg/pr28796-1.c: Add more cases.
	* gcc.dg/pr28796-2.c: Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/c-cppbuiltin.c
    trunk/gcc/real.c
    trunk/gcc/real.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr28796-1.c
    trunk/gcc/testsuite/gcc.dg/pr28796-2.c

Comment 7 Kaveh Ghazi 2007-07-18 17:42:22 UTC
Subject: Bug 30652

Author: ghazi
Date: Wed Jul 18 17:42:12 2007
New Revision: 126725

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126725
Log:
	PR target/30652

	* builtins.c (expand_builtin_interclass_mathfn): Allow for missing
	optabs infrastructure.  Provide generic implementation for
	FINITE/ISFINITE.
	(expand_builtin): Handle FINITE/ISFINITE.
	(fold_builtin_classify): Make ISFINITE canonical instead of FINITE.
	(fold_builtin_1): Likewise.

	* builtins.def (BUILT_IN_ISFINITE): New.

	* doc/extend.texi: Document isfinite.

testsuite:
	* gcc.dg/pr28796-1.c: Add more cases.
	* gcc.dg/pr28796-2.c: Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/builtins.def
    trunk/gcc/doc/extend.texi
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr28796-1.c
    trunk/gcc/testsuite/gcc.dg/pr28796-2.c

Comment 8 Kaveh Ghazi 2007-07-18 17:51:23 UTC
Subject: Bug 30652

Author: ghazi
Date: Wed Jul 18 17:51:13 2007
New Revision: 126726

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126726
Log:
	PR target/30652

	* builtins.c (expand_builtin_interclass_mathfn): Provide a generic
	transformation for builtin ISNORMAL.
	(expand_builtin): Handle BUILT_IN_ISNORMAL.
	* builtins.def (BUILT_IN_ISNORMAL): New.
	* doc/extend.texi: Document isnormal.

testsuite:
	* gcc.dg/pr28796-2.c: Add more cases.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/builtins.def
    trunk/gcc/doc/extend.texi
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr28796-2.c

Comment 9 Kaveh Ghazi 2007-07-18 18:00:56 UTC
Generic implementations for isinf, isfinite and isnormal installed on trunk.

Still possibly want optabs where it is profitable.

Also, isnan doesn't allow for optabs at the moment.  Should convert it into this system.

Comment 10 Richard Biener 2008-03-14 16:45:11 UTC
Only partly fixed.
Comment 11 Kaveh Ghazi 2008-06-07 04:02:31 UTC
What remains to be done for this PR?

The generic FP classification implementations are all done, including builtin fpclassify().  Perhaps some optabs still need to be finished?  Or can we close this one?

Comment 12 Kaveh Ghazi 2009-11-22 17:58:17 UTC
What remains to be done here?