* Re: [PATCH] Optimize abs(x) < 0.0
@ 2002-07-23 16:09 Joern Rennecke
2002-07-23 18:44 ` Roger Sayle
0 siblings, 1 reply; 42+ messages in thread
From: Joern Rennecke @ 2002-07-23 16:09 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc-patches, Roger Sayle, Toon Moene
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
For the sh64 target, this optimization fails when using software
floating point, and for -m5-compact [-ml].
--
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330
[-- Attachment #2: 20020720-1.c-failures --]
[-- Type: text/plain, Size: 4570 bytes --]
grep -c 'FAIL: gcc.c-torture/execute/20020720-1.c compilation' testsuite-m5*/gcc.log
testsuite-m5-32media-nofpu/gcc.log:5
testsuite-m5-32media-nofpu-ml/gcc.log:5
testsuite-m5-64media/gcc.log:0
testsuite-m5-64media-ml/gcc.log:0
testsuite-m5-64media-nofpu/gcc.log:5
testsuite-m5-64media-nofpu-ml/gcc.log:5
testsuite-m5-compact/gcc.log:5
testsuite-m5-compact-ml/gcc.log:5
testsuite-m5-compact-nofpu/gcc.log:5
testsuite-m5-compact-nofpu-ml/gcc.log:5
testsuite-m5/gcc.log:0
testsuite-m5-ml/gcc.log:0
grep 'FAIL: gcc.c-torture/execute/20020720-1.c compilation' testsuite-m5*/gcc.log
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-32media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-32media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-64media-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-64media-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-compact/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-compact-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-compact-nofpu/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O1
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O2
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -fomit-frame-pointer
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -O3 -g
testsuite-m5-compact-nofpu-ml/gcc.log:FAIL: gcc.c-torture/execute/20020720-1.c compilation, -Os
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 16:09 [PATCH] Optimize abs(x) < 0.0 Joern Rennecke
@ 2002-07-23 18:44 ` Roger Sayle
2002-07-23 18:51 ` Andrew Pinski
` (2 more replies)
0 siblings, 3 replies; 42+ messages in thread
From: Roger Sayle @ 2002-07-23 18:44 UTC (permalink / raw)
To: gcc-patches; +Cc: Richard Henderson, Joern Rennecke
> For the sh64 target, this optimization fails when using software
> floating point, and for -m5-compact [-ml].
Oh well. It looks like its just a fact of life that some GCC
backends allow more optimizations than others. Probably best
to just delete the testcase for the time being.
Ok for mainline?
2002-07-23 Roger Sayle <roger@eyesopen.com>
* gcc.c-torture/execute/20020720-1.c: Delete testcase as not
all machine descriptions expose optimization opportunity.
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 18:44 ` Roger Sayle
@ 2002-07-23 18:51 ` Andrew Pinski
2002-07-23 19:49 ` Richard Henderson
2002-07-23 20:16 ` Kaveh R. Ghazi
2 siblings, 0 replies; 42+ messages in thread
From: Andrew Pinski @ 2002-07-23 18:51 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches, Richard Henderson, Joern Rennecke
What about disabling the case for the ones that fail, right now?
Thanks,
Andrew Pinski
On Tuesday, July 23, 2002, at 09:26 , Roger Sayle wrote:
> gcc.c-torture/execute/20020720-1.c
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 18:44 ` Roger Sayle
2002-07-23 18:51 ` Andrew Pinski
@ 2002-07-23 19:49 ` Richard Henderson
2002-07-23 20:16 ` Kaveh R. Ghazi
2 siblings, 0 replies; 42+ messages in thread
From: Richard Henderson @ 2002-07-23 19:49 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches, Joern Rennecke
On Tue, Jul 23, 2002 at 07:26:50PM -0600, Roger Sayle wrote:
> * gcc.c-torture/execute/20020720-1.c: Delete testcase as not
> all machine descriptions expose optimization opportunity.
You could move it to gcc.dg, and control based on the
platforms for which it is known to work. That way you
can at least detect regressions.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 18:44 ` Roger Sayle
2002-07-23 18:51 ` Andrew Pinski
2002-07-23 19:49 ` Richard Henderson
@ 2002-07-23 20:16 ` Kaveh R. Ghazi
2002-07-23 21:58 ` Roger Sayle
2 siblings, 1 reply; 42+ messages in thread
From: Kaveh R. Ghazi @ 2002-07-23 20:16 UTC (permalink / raw)
To: rth; +Cc: gcc-patches, joern.rennecke, roger
> From: Richard Henderson
>
> On Tue, Jul 23, 2002 at 07:26:50PM -0600, Roger Sayle wrote:
> > * gcc.c-torture/execute/20020720-1.c: Delete testcase as not
> > all machine descriptions expose optimization opportunity.
>
> You could move it to gcc.dg, and control based on the
> platforms for which it is known to work. That way you
> can at least detect regressions.
> r~
No need to move the test, you can XFAIL from within the
gcc.c-torture/execute directory also.
E.g. see execute/20020227-1.x et al.
--
Kaveh R. Ghazi Director of Systems Architecture
ghazi@caip.rutgers.edu Qwest Solutions
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 20:16 ` Kaveh R. Ghazi
@ 2002-07-23 21:58 ` Roger Sayle
2002-07-23 22:07 ` Kaveh R. Ghazi
0 siblings, 1 reply; 42+ messages in thread
From: Roger Sayle @ 2002-07-23 21:58 UTC (permalink / raw)
To: Joern Rennecke, David Edelsohn, gcc-patches
Cc: Richard Henderson, Kaveh R. Ghazi
Hi Joern and David,
I was wondering if you could please test the following patch to
mark gcc.c-torture/execute/20020720-1.c as XFAIL on your platforms.
I've checked that this doesn't break "make check" on i686-pc-linux-gnu
but I have absolutely no idea whether it has any other effect on
any other platform :>
I'd also appreciate it if somebody on the mailing list that understands
how these things are supposed to work could confirm that the file below
does whats intended.
Many thanks in advance,
2002-07-23 Roger Sayle <roger@eyesopen.com>
* gcc.c-torture/execute/20020720-1.x: Mark MIPS, AIX and
some compiler flags on sh64 as XFAIL.
*** /dev/null Thu Aug 30 14:30:55 2001
--- gcc.c-torture/execute/20020720-1.x Tue Jul 23 21:25:22 2002
***************
*** 0 ****
--- 1,15 ----
+ # This test has been reported to fail on AIX and MIPS.
+ if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
+ || [istarget "mips*-*-*"] } {
+ set torture_execute_xfail [istarget]
+ }
+
+ # This test has also been reported to fail on sh64 with specific flags
+ if { [istarget "sh64*-*-*"] } {
+ if { [string match "*nofpu*" $CFLAGS] \
+ || [string match "*compact*" $CFLAGS] } {
+ set torture_execute_xfail [istarget]
+ }
+ }
+
+ return 0
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 21:58 ` Roger Sayle
@ 2002-07-23 22:07 ` Kaveh R. Ghazi
2002-07-24 7:47 ` Roger Sayle
0 siblings, 1 reply; 42+ messages in thread
From: Kaveh R. Ghazi @ 2002-07-23 22:07 UTC (permalink / raw)
To: dje, gcc-patches, joern.rennecke, roger; +Cc: rth
> From: Roger Sayle <roger@eyesopen.com>
>
> I'd also appreciate it if somebody on the mailing list that
> understands how these things are supposed to work could confirm that
> the file below does whats intended.
>
> *** /dev/null Thu Aug 30 14:30:55 2001
> --- gcc.c-torture/execute/20020720-1.x Tue Jul 23 21:25:22 2002
> ***************
> *** 0 ****
> --- 1,15 ----
> + # This test has been reported to fail on AIX and MIPS.
> + if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
> + || [istarget "mips*-*-*"] } {
> + set torture_execute_xfail [istarget]
> + }
I'm pretty sure that your testcase always succeeds at -O0 in which
case the above will spuriously yield an XPASS at -O0. I *think* that
if instead of setting torture_execute_xfail you "return 1" it'll
bypass the test entirely rather than run it and that should give you
clean results. But I could be wrong.
Note you *can* test the .x file by putting your target in the list and
inserting a syntax error into the testcase. That will test whether
the xfail is setup properly.
> + # This test has also been reported to fail on sh64 with specific flags
> + if { [istarget "sh64*-*-*"] } {
> + if { [string match "*nofpu*" $CFLAGS] \
> + || [string match "*compact*" $CFLAGS] } {
> + set torture_execute_xfail [istarget]
> + }
> + }
> +
> + return 0
This may not work, I seem to recall that CFLAGS doesn't always contain
what you want. Instead try using torture_eval_before_execute &
compiler_conditional_xfail_data. Again, see execute/20020227-1.x.
--Kaveh
--
Kaveh R. Ghazi Director of Systems Architecture
ghazi@caip.rutgers.edu Qwest Solutions
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-23 22:07 ` Kaveh R. Ghazi
@ 2002-07-24 7:47 ` Roger Sayle
2002-07-24 8:25 ` Joern Rennecke
0 siblings, 1 reply; 42+ messages in thread
From: Roger Sayle @ 2002-07-24 7:47 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: dje, gcc-patches, joern.rennecke, rth
Hi Kaveh,
> I'm pretty sure that your testcase always succeeds at -O0 in which
> case the above will spuriously yield an XPASS at -O0. I *think* that
> if instead of setting torture_execute_xfail you "return 1" it'll
> bypass the test entirely rather than run it and that should give you
> clean results. But I could be wrong.
Thanks for taking a look at this. And yes the test case would XPASS at
-O0. I've made the suggested changes to "return 1" in my local copy.
> > + # This test has also been reported to fail on sh64 with specific flags
> > + if { [istarget "sh64*-*-*"] } {
> > + if { [string match "*nofpu*" $CFLAGS] \
> > + || [string match "*compact*" $CFLAGS] } {
> > + set torture_execute_xfail [istarget]
> > + }
> > + }
> > +
> > + return 0
>
> This may not work, I seem to recall that CFLAGS doesn't always contain
> what you want. Instead try using torture_eval_before_execute &
> compiler_conditional_xfail_data. Again, see execute/20020227-1.x.
This issue I'd like to leave to Joern. The SH test results posted
to the gcc-testresults list don't show the problem, and the compiler
flags that cause the sh64 failures weren't mentioned in Joern's posting
and aren't described in the GCC documentation. Hopefully Joern can
determine if the the substrings above appear in the $CFLAGS with the
invocations he uses.
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-24 7:47 ` Roger Sayle
@ 2002-07-24 8:25 ` Joern Rennecke
2002-07-24 22:20 ` Roger Sayle
0 siblings, 1 reply; 42+ messages in thread
From: Joern Rennecke @ 2002-07-24 8:25 UTC (permalink / raw)
To: Roger Sayle; +Cc: Kaveh R. Ghazi, dje, gcc-patches, rth
Roger Sayle wrote:
> > This may not work, I seem to recall that CFLAGS doesn't always contain
> > what you want. Instead try using torture_eval_before_execute &
> > compiler_conditional_xfail_data. Again, see execute/20020227-1.x.
>
> This issue I'd like to leave to Joern. The SH test results posted
> to the gcc-testresults list don't show the problem, and the compiler
> flags that cause the sh64 failures weren't mentioned in Joern's posting
> and aren't described in the GCC documentation. Hopefully Joern can
> determine if the the substrings above appear in the $CFLAGS with the
> invocations he uses.
I've tested your patch, and it doesn't work.
--
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-24 8:25 ` Joern Rennecke
@ 2002-07-24 22:20 ` Roger Sayle
2002-07-25 10:30 ` Richard Henderson
0 siblings, 1 reply; 42+ messages in thread
From: Roger Sayle @ 2002-07-24 22:20 UTC (permalink / raw)
To: gcc-patches
Cc: Kaveh R. Ghazi, Joern Rennecke, Bob Wilson, David Edelsohn,
Richard Henderson
After building a toolchain and cross-compiler to sh-elf and running
the testsuite on the sh-hms-sim simulator, I've discovered that the
testcase also fails on vanilla "sh-*-*" without any special compiler
options for me.
I've tested the patch below on the sh-hms-sim simulator and confirmed
that the 20020720-1.c tests no longer appear in the list of failures.
This revision lists all the targets I currently know to fail.
Ok for mainline?
[I also believe that I may yet be able to implement this optimization
on some of the failing targets with a patch to combine.c that implements
a four instruction combination.]
2002-07-23 Roger Sayle <roger@eyesopen.com>
gcc.c-torture/execute/20020720-1.x: Skip this test on
several targets known to fail.
*** /dev/null Thu Aug 30 14:30:55 2001
--- gcc.c-torture/execute/20020720-1.x Wed Jul 24 20:28:03 2002
***************
*** 0 ****
--- 1,8 ----
+ # This test, 20020720-1.c, fails on the following targets:
+ if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
+ || [istarget "mips*-*-*"] || [istarget "xtensa-*-*"] \
+ || [istarget "sh-*-*"] } {
+ return 1
+ }
+
+ return 0
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-24 22:20 ` Roger Sayle
@ 2002-07-25 10:30 ` Richard Henderson
2002-07-25 10:37 ` Bob Wilson
2002-07-25 14:49 ` Roger Sayle
0 siblings, 2 replies; 42+ messages in thread
From: Richard Henderson @ 2002-07-25 10:30 UTC (permalink / raw)
To: Roger Sayle
Cc: gcc-patches, Kaveh R. Ghazi, Joern Rennecke, Bob Wilson, David Edelsohn
On Wed, Jul 24, 2002 at 10:33:31PM -0600, Roger Sayle wrote:
> + # This test, 20020720-1.c, fails on the following targets:
Please expand on the reasons why the test fails. That it fails
is obvious from the fact that we're attempting not to test it.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-25 10:30 ` Richard Henderson
@ 2002-07-25 10:37 ` Bob Wilson
2002-07-25 14:49 ` Roger Sayle
1 sibling, 0 replies; 42+ messages in thread
From: Bob Wilson @ 2002-07-25 10:37 UTC (permalink / raw)
To: Richard Henderson
Cc: Roger Sayle, gcc-patches, Kaveh R. Ghazi, Joern Rennecke, David Edelsohn
Richard Henderson wrote:
> On Wed, Jul 24, 2002 at 10:33:31PM -0600, Roger Sayle wrote:
>
>>+ # This test, 20020720-1.c, fails on the following targets:
>
>
> Please expand on the reasons why the test fails. That it fails
> is obvious from the fact that we're attempting not to test it.
I haven't investigated the Xtensa failure in detail, but I assume it is because
the default Xtensa processor configuration does not include hardware support for
floating-point operations. The RTL will never contain FLOAT_EXTEND operations
and Roger's patch has no effect. It doesn't hurt anything, either, except that
the test requires the call to link_error() be optimized away and that doesn't
happen.
--Bob
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-25 10:30 ` Richard Henderson
2002-07-25 10:37 ` Bob Wilson
@ 2002-07-25 14:49 ` Roger Sayle
2002-07-25 16:17 ` Richard Henderson
1 sibling, 1 reply; 42+ messages in thread
From: Roger Sayle @ 2002-07-25 14:49 UTC (permalink / raw)
To: Richard Henderson
Cc: gcc-patches, Kaveh R. Ghazi, Joern Rennecke, Bob Wilson, David Edelsohn
Hi Richard,
> Please expand on the reasons why the test fails. That it fails
> is obvious from the fact that we're attempting not to test it.
How about the following? I guess I must have been (un)lucky that
the two platforms that I tested my original patch on (alpha and
i386) where able to handle the test case without difficulty. As
I mentioned in my previous mail, I'm working on a patch that should
also fix the powerpc failures.
2002-07-25 Roger Sayle <roger@eyesopen.com>
gcc.c-torture/execute/20020720-1.x: Skip this test on
several targets known to fail.
*** /dev/null Thu Aug 30 14:30:55 2001
--- 20020720-1.x Thu Jul 25 15:17:22 2002
***************
*** 0 ****
--- 1,16 ----
+ # The following targets fail 20020720-1.c for several reasons:
+ # (1) They implement floating point instructions via software, or
+ # (2) Their machine descriptions obfuscate the "abs(x) < 0.0" comparison.
+ # For example, 1 insn performs abs, 1 insn loads 0.0, 1 insn sets
+ # CC mode flags based upon the FP comparison, and a 4th insn makes
+ # a conditional branch based upon the appropriate bits in the flags.
+ # If the intermediate comparison can't be recognized, the combiner
+ # is unable to optimize all four RTL instructions simultaneously.
+
+ if { [istarget "powerpc-*-*"] || [istarget "rs6000-*-*"] \
+ || [istarget "mips*-*-*"] || [istarget "xtensa-*-*"] \
+ || [istarget "sh-*-*"] } {
+ return 1
+ }
+
+ return 0
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-25 14:49 ` Roger Sayle
@ 2002-07-25 16:17 ` Richard Henderson
2002-07-25 20:15 ` Roger Sayle
0 siblings, 1 reply; 42+ messages in thread
From: Richard Henderson @ 2002-07-25 16:17 UTC (permalink / raw)
To: Roger Sayle
Cc: gcc-patches, Kaveh R. Ghazi, Joern Rennecke, Bob Wilson, David Edelsohn
On Thu, Jul 25, 2002 at 03:24:38PM -0600, Roger Sayle wrote:
> I mentioned in my previous mail, I'm working on a patch that should
> also fix the powerpc failures.
If this is about making combine match 4 insns, don't.
That'll touch write-only code for sure.
Better to have the abs patterns split post-reload.
> gcc.c-torture/execute/20020720-1.x: Skip this test on
> several targets known to fail.
Ok.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-25 16:17 ` Richard Henderson
@ 2002-07-25 20:15 ` Roger Sayle
0 siblings, 0 replies; 42+ messages in thread
From: Roger Sayle @ 2002-07-25 20:15 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc-patches
On Thu, 25 Jul 2002, Richard Henderson wrote:
> On Thu, Jul 25, 2002 at 03:24:38PM -0600, Roger Sayle wrote:
> > I mentioned in my previous mail, I'm working on a patch that should
> > also fix the powerpc failures.
>
> If this is about making combine match 4 insns, don't.
> That'll touch write-only code for sure.
>
> Better to have the abs patterns split post-reload.
The plan is actually not that intrusive. Rather then generic 4
insn matching in combine, I'm hoping to tweak simplify_set which
already identifies the "fourth" CCmode user instruction via
"cc_use = find_single_use(...)". Then before calling the
function simplify_comparison, which doesn't handle always
true/always false comparisons, call simplify_relational_operation
which does. If simplify_relational_operation returns non-NULL,
we can delete the current insn and optimize its use at cc_use.
Its using combine's SUBST machinery to delete the current insn
and optimize cc_use via undobuf.other_insn thats just beyond my
current skill level. For example, I'm unsure if combine/recog
can handle/recognize INSN_DELETED notes.
> > gcc.c-torture/execute/20020720-1.x: Skip this test on
> > several targets known to fail.
>
> Ok.
Many thanks. Applied.
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
@ 2002-07-24 11:35 Bob Wilson
0 siblings, 0 replies; 42+ messages in thread
From: Bob Wilson @ 2002-07-24 11:35 UTC (permalink / raw)
To: roger; +Cc: gcc-patches
This test should also be skipped or marked as XFAIL for -O1 and higher
optimization levels for xtensa-*-* targets. If you haven't yet
committed the patch, please add that. Otherwise, let me know and I'll
add it separately.
--Bob
> I was wondering if you could please test the following patch to
> mark gcc.c-torture/execute/20020720-1.c as XFAIL on your platforms.
> I've checked that this doesn't break "make check" on i686-pc-linux-gnu
> but I have absolutely no idea whether it has any other effect on
> any other platform :>
>
> I'd also appreciate it if somebody on the mailing list that understands
> how these things are supposed to work could confirm that the file below
> does whats intended.
>
> Many thanks in advance,
>
>
> 2002-07-23 Roger Sayle <roger@eyesopen.com>
>
> * gcc.c-torture/execute/20020720-1.x: Mark MIPS, AIX and
> some compiler flags on sh64 as XFAIL.
>
>
> *** /dev/null Thu Aug 30 14:30:55 2001
> --- gcc.c-torture/execute/20020720-1.x Tue Jul 23 21:25:22 2002
> ***************
> *** 0 ****
> --- 1,15 ----
> + # This test has been reported to fail on AIX and MIPS.
> + if { [istarget "powerpc-*-aix*"] || [istarget "rs6000-*-aix*"] \
> + || [istarget "mips*-*-*"] } {
> + set torture_execute_xfail [istarget]
> + }
> +
> + # This test has also been reported to fail on sh64 with specific flags
> + if { [istarget "sh64*-*-*"] } {
> + if { [string match "*nofpu*" $CFLAGS] \
> + || [string match "*compact*" $CFLAGS] } {
> + set torture_execute_xfail [istarget]
> + }
> + }
> +
> + return 0
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 19:54 ` Roger Sayle
@ 2002-07-22 20:18 ` David Edelsohn
0 siblings, 0 replies; 42+ messages in thread
From: David Edelsohn @ 2002-07-22 20:18 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches
It surprises me that this seems to work on PowerPC Linux, but not
AIX -- not even with I target a PowerPC processor instead of common mode
(in case that made a difference).
Thanks, David
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 19:45 ` David Edelsohn
@ 2002-07-22 19:54 ` Roger Sayle
2002-07-22 20:18 ` David Edelsohn
0 siblings, 1 reply; 42+ messages in thread
From: Roger Sayle @ 2002-07-22 19:54 UTC (permalink / raw)
To: David Edelsohn; +Cc: gcc-patches
> Your new testcase is fails on AIX for some reason.
Ahh! As Richard Henderson had feared:
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01103.html
I'll see if there's anything I can do to fix it on the AIX
box I have here. If I don't have a solution in a day or two,
we can either delete the test entirely or mark it XFAIL on
the powerpc.
Sorry for any inconvenience this may have caused.
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-20 11:42 Roger Sayle
2002-07-20 15:30 ` Richard Henderson
2002-07-21 9:08 ` Toon Moene
@ 2002-07-22 19:45 ` David Edelsohn
2002-07-22 19:54 ` Roger Sayle
2 siblings, 1 reply; 42+ messages in thread
From: David Edelsohn @ 2002-07-22 19:45 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches
Your new testcase is fails on AIX for some reason.
David
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 14:09 Brad Lucier
@ 2002-07-22 14:46 ` Gabriel Dos Reis
0 siblings, 0 replies; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-22 14:46 UTC (permalink / raw)
To: Brad Lucier; +Cc: gcc-patches
Brad Lucier <lucier@math.purdue.edu> writes:
[...]
| > The proposed transformation doesn't preserve semantics in presence
| > of signaling NaNs. I suggest it to be applied only either unsafe-math
| > or say -fno-nan-values or whatever.
|
| There is an option -fno-trapping-math that tells the compiler that
| the libraries are set up to do no trapping of floating-point arithmetic;
| perhaps the transformation should be predicated on this flag.
That is indeed a good suggestion. Roger is working on a flag
-fsignaling-nan, maybe be they could be combined, say
-fno-trapping-math implying -fno-signaling-nan?
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
@ 2002-07-22 14:09 Brad Lucier
2002-07-22 14:46 ` Gabriel Dos Reis
0 siblings, 1 reply; 42+ messages in thread
From: Brad Lucier @ 2002-07-22 14:09 UTC (permalink / raw)
To: gcc-patches; +Cc: lucier
> Richard Henderson <rth@redhat.com> writes:
>
> | On Mon, Jul 22, 2002 at 09:34:03AM +0200, Gabriel Dos Reis wrote:
> | > Then, what does GCC return for fabs(x) when x is a signaling NaN?
> |
> | An SNaN with the sign bit clear.
>
> Therefore the expression fabs(x) < 0.0 may trap.
>
> Removing that expression in the proposed transformation changes
> that behaviour.
>
> The proposed transformation doesn't preserve semantics in presence
> of signaling NaNs. I suggest it to be applied only either unsafe-math
> or say -fno-nan-values or whatever.
There is an option -fno-trapping-math that tells the compiler that
the libraries are set up to do no trapping of floating-point arithmetic;
perhaps the transformation should be predicated on this flag.
Brad
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 11:10 ` Richard Henderson
@ 2002-07-22 11:21 ` Gabriel Dos Reis
0 siblings, 0 replies; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-22 11:21 UTC (permalink / raw)
To: Richard Henderson; +Cc: Roger Sayle, gcc-patches
Richard Henderson <rth@redhat.com> writes:
[...]
| I tell you that there are a *lot* of places in the
| compiler where we do not conserve fp signals. We cannot
| possibly promise that we will not lose any, and I guess
| becuase of that, I feel no need to preserve them either.
I hear you. However, I'm not convinced that because we didn't take
care of the issue in the past means that we should continue not to
take care of it. I think new transformations should try hard to
locate where they are not preserving fp signals and use appropriate
flags.
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 10:24 ` Gabriel Dos Reis
@ 2002-07-22 11:10 ` Richard Henderson
2002-07-22 11:21 ` Gabriel Dos Reis
0 siblings, 1 reply; 42+ messages in thread
From: Richard Henderson @ 2002-07-22 11:10 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Roger Sayle, gcc-patches
On Mon, Jul 22, 2002 at 06:26:45PM +0200, Gabriel Dos Reis wrote:
> Therefore the expression fabs(x) < 0.0 may trap.
Or, it may not. We might choose to reverse the branch,
which means using the UNGE comparator, which uses the
non-trapping fcmpd instead of the trapping fcmped insn.
I tell you that there are a *lot* of places in the
compiler where we do not conserve fp signals. We cannot
possibly promise that we will not lose any, and I guess
becuase of that, I feel no need to preserve them either.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 10:18 ` Richard Henderson
@ 2002-07-22 10:24 ` Gabriel Dos Reis
2002-07-22 11:10 ` Richard Henderson
0 siblings, 1 reply; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-22 10:24 UTC (permalink / raw)
To: Richard Henderson; +Cc: Roger Sayle, gcc-patches
Richard Henderson <rth@redhat.com> writes:
| On Mon, Jul 22, 2002 at 09:34:03AM +0200, Gabriel Dos Reis wrote:
| > Then, what does GCC return for fabs(x) when x is a signaling NaN?
|
| An SNaN with the sign bit clear.
Therefore the expression fabs(x) < 0.0 may trap.
Removing that expression in the proposed transformation changes
that behaviour.
The proposed transformation doesn't preserve semantics in presence
of signaling NaNs. I suggest it to be applied only either unsafe-math
or say -fno-nan-values or whatever.
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-22 0:54 ` Gabriel Dos Reis
@ 2002-07-22 10:18 ` Richard Henderson
2002-07-22 10:24 ` Gabriel Dos Reis
0 siblings, 1 reply; 42+ messages in thread
From: Richard Henderson @ 2002-07-22 10:18 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Roger Sayle, gcc-patches
On Mon, Jul 22, 2002 at 09:34:03AM +0200, Gabriel Dos Reis wrote:
> Then, what does GCC return for fabs(x) when x is a signaling NaN?
An SNaN with the sign bit clear.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 19:43 ` Richard Henderson
@ 2002-07-22 0:54 ` Gabriel Dos Reis
2002-07-22 10:18 ` Richard Henderson
0 siblings, 1 reply; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-22 0:54 UTC (permalink / raw)
To: Richard Henderson; +Cc: Roger Sayle, gcc-patches
Richard Henderson <rth@redhat.com> writes:
| > 2) Even in the case where fabs(x)
| > may not cause a trap by itself, the expression
| >
| > fabs(x) < 0.0
| >
| > may because of the comparaison (SPARC V9 for example has mode to
| > trigger exception when comparing a signaling NaN against something).
|
| We don't preserve signals anywere else in gcc (e.g. eliminated
| because the result is dead). I don't see why we should start now.
Then, what does GCC return for fabs(x) when x is a signaling NaN?
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 17:16 ` Gabriel Dos Reis
@ 2002-07-21 19:43 ` Richard Henderson
2002-07-22 0:54 ` Gabriel Dos Reis
0 siblings, 1 reply; 42+ messages in thread
From: Richard Henderson @ 2002-07-21 19:43 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Roger Sayle, gcc-patches
> 2) Even in the case where fabs(x)
> may not cause a trap by itself, the expression
>
> fabs(x) < 0.0
>
> may because of the comparaison (SPARC V9 for example has mode to
> trigger exception when comparing a signaling NaN against something).
We don't preserve signals anywere else in gcc (e.g. eliminated
because the result is dead). I don't see why we should start now.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 15:59 ` Roger Sayle
2002-07-21 16:02 ` Toon Moene
@ 2002-07-21 17:16 ` Gabriel Dos Reis
2002-07-21 19:43 ` Richard Henderson
1 sibling, 1 reply; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-21 17:16 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches
Roger Sayle <roger@eyesopen.com> writes:
| On 21 Jul 2002, Gabriel Dos Reis wrote:
| > Michael Matz <matz@suse.de> writes:
| > | > The issue is that floating-point comparaison is tree-valued (true,
| > | > false, undordered). In case of the NaN case abs(x) should return
| > | > 'unordered' (not false)
| > |
| > | But it doesn't and can't in C. What it should or should not returns is
| > | irrelevant here.
| >
| > I disagree that what comes out of abs(x) is irrelevant here. If
| > abs(x) should have raised a floating-point exception then, that does
| > matter.
|
| I've just come across the following ISO C standards URL:
| http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
| Document N965 of Working Group JTC1/SC22/WG14 entitled
| "Optional support for Signaling NaNs".
Thanks for inputing references into this discussion.
| It includes the paragraph:
|
| >> Whether an operation that merely returns the value of a numeric
| >> operand, changing at most its sign, triggers signaling NaNs is
| >> unspecified. Such operations include conversions that do not change
| >> precision, the unary + and - operators, and the fabs and copysign
| >> functions.
|
| It would appear that "fabs" is not required to trigger a signal in
| ISO C's optional extensions. Hence the transformation is safe even
| in the presence of (the future extension) "-fsignaling-nans".
No, I don't think it is safe in that case. 1) It is true that the
above wording does not require fabs(x) to trigger a trap; but it
doesn't not forbid trapping either. 2) Even in the case where fabs(x)
may not cause a trap by itself, the expression
fabs(x) < 0.0
may because of the comparaison (SPARC V9 for example has mode to
trigger exception when comparing a signaling NaN against something).
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 15:59 ` Roger Sayle
@ 2002-07-21 16:02 ` Toon Moene
2002-07-21 17:16 ` Gabriel Dos Reis
1 sibling, 0 replies; 42+ messages in thread
From: Toon Moene @ 2002-07-21 16:02 UTC (permalink / raw)
To: Roger Sayle; +Cc: Gabriel Dos Reis, gcc-patches
Roger Sayle wrote:
> I've just come across the following ISO C standards URL:
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
> Document N965 of Working Group JTC1/SC22/WG14 entitled
> "Optional support for Signaling NaNs".
>
> It includes the paragraph:
>
> >> Whether an operation that merely returns the value of a numeric
> >> operand, changing at most its sign, triggers signaling NaNs is
> >> unspecified. Such operations include conversions that do not change
> >> precision, the unary + and - operators, and the fabs and copysign
> >> functions.
>
> It would appear that "fabs" is not required to trigger a signal in
> ISO C's optional extensions. Hence the transformation is safe even
> in the presence of (the future extension) "-fsignaling-nans".
Well, until there's a language that goes above and beyond ISO's C (think
Fortran 2004).
:-)
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 12:21 ` Gabriel Dos Reis
@ 2002-07-21 15:59 ` Roger Sayle
2002-07-21 16:02 ` Toon Moene
2002-07-21 17:16 ` Gabriel Dos Reis
0 siblings, 2 replies; 42+ messages in thread
From: Roger Sayle @ 2002-07-21 15:59 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc-patches
On 21 Jul 2002, Gabriel Dos Reis wrote:
> Michael Matz <matz@suse.de> writes:
> | > The issue is that floating-point comparaison is tree-valued (true,
> | > false, undordered). In case of the NaN case abs(x) should return
> | > 'unordered' (not false)
> |
> | But it doesn't and can't in C. What it should or should not returns is
> | irrelevant here.
>
> I disagree that what comes out of abs(x) is irrelevant here. If
> abs(x) should have raised a floating-point exception then, that does
> matter.
I've just come across the following ISO C standards URL:
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
Document N965 of Working Group JTC1/SC22/WG14 entitled
"Optional support for Signaling NaNs".
It includes the paragraph:
>> Whether an operation that merely returns the value of a numeric
>> operand, changing at most its sign, triggers signaling NaNs is
>> unspecified. Such operations include conversions that do not change
>> precision, the unary + and - operators, and the fabs and copysign
>> functions.
It would appear that "fabs" is not required to trigger a signal in
ISO C's optional extensions. Hence the transformation is safe even
in the presence of (the future extension) "-fsignaling-nans".
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 11:19 ` Michael Matz
@ 2002-07-21 12:21 ` Gabriel Dos Reis
2002-07-21 15:59 ` Roger Sayle
0 siblings, 1 reply; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-21 12:21 UTC (permalink / raw)
To: Michael Matz; +Cc: Roger Sayle, Toon Moene, gcc-patches
Michael Matz <matz@suse.de> writes:
[...]
| > The issue is that floating-point comparaison is tree-valued (true,
| > false, undordered). In case of the NaN case abs(x) should return
| > 'unordered' (not false)
|
| But it doesn't and can't in C. What it should or should not returns is
| irrelevant here.
I disagree that what comes out of abs(x) is irrelevant here. If
abs(x) should have raised a floating-point exception then, that does
matter.
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 11:16 ` Toon Moene
@ 2002-07-21 12:20 ` Gabriel Dos Reis
0 siblings, 0 replies; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-21 12:20 UTC (permalink / raw)
To: Toon Moene; +Cc: Roger Sayle, gcc-patches
Toon Moene <toon@moene.indiv.nluug.nl> writes:
[...]
| The code in the patch is OK because it doesn't introduce a hole where there
| wasn't one before :-)
I'm not sure I agree: If x is a signaling NaN, then abs(x) can raise
a floating-point exception (if toggled). The optimisation removes
that behaviour.
It is true that C leaves signaling NaNs as implementation defined
issues, but I find the definition in the patch rather drastic :-)
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 11:05 ` Gabriel Dos Reis
@ 2002-07-21 11:19 ` Michael Matz
2002-07-21 12:21 ` Gabriel Dos Reis
0 siblings, 1 reply; 42+ messages in thread
From: Michael Matz @ 2002-07-21 11:19 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Roger Sayle, Toon Moene, gcc-patches
Hi,
On 21 Jul 2002, Gabriel Dos Reis wrote:
> I'm not sure I agree with your reasoning.
Well, if there is no program which delivers a different answer depending
on the presence of optimization X, then X is correct. Can you think about
any such program for this particular optimization?
> The issue is that floating-point comparaison is tree-valued (true,
> false, undordered). In case of the NaN case abs(x) should return
> 'unordered' (not false)
But it doesn't and can't in C. What it should or should not returns is
irrelevant here.
Maybe there are languages, where you can have a three-valued logic, but
for the languages currently implemented by GCC (not sure about Ada,
though) this isn't the case, so the optimization is correct in this
context. Sure, the context could be another one, where this wouldn't be
correct, but it isn't.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 10:04 ` Roger Sayle
2002-07-21 11:05 ` Gabriel Dos Reis
@ 2002-07-21 11:16 ` Toon Moene
2002-07-21 12:20 ` Gabriel Dos Reis
1 sibling, 1 reply; 42+ messages in thread
From: Toon Moene @ 2002-07-21 11:16 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches
Roger Sayle wrote:
> > Now computer hardware is forced to project that three valued logic onto a
> > two valued logical "true, false" dichotomy. The solution chosen is to have
> > both comparisons above return "false". That means that to check for a NaN
> > and use a > or <= comparison, you have to use *both*, else the NaN will
> > just escape your check.
>
> When applying a code transformation it is sufficient to guarantee that
> the behaviour of the transformed code is the same as the original.
> In this case, I don't have to explicitly "check for a NaN" with two
> comparisons iff the optimized code produces the same results in the
> presence of NaNs and finite values.
Yep, rethinking this, it is the original code writer who should make sure
that abs(a) < 0.0 is the correct check, i.e.:
> [You might also appreciate that "x == x" is a better explicit check
> for finite vs. NaN that would require only a single comparison]
He/she should have done the above check.
The code in the patch is OK because it doesn't introduce a hole where there
wasn't one before :-)
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 10:04 ` Roger Sayle
@ 2002-07-21 11:05 ` Gabriel Dos Reis
2002-07-21 11:19 ` Michael Matz
2002-07-21 11:16 ` Toon Moene
1 sibling, 1 reply; 42+ messages in thread
From: Gabriel Dos Reis @ 2002-07-21 11:05 UTC (permalink / raw)
To: Roger Sayle; +Cc: Toon Moene, gcc-patches
Roger Sayle <roger@eyesopen.com> writes:
[...]
| Your suggestion of requiring two tests to check for a NaN amounts to
|
| (x<0.0) || (x>=0.0)? finite_case : NaN_case
|
| where finite_case of "abs(x) < 0.0" always returns false, and the
| NaN_case "abs(NaN) < 0.0" is "NaN < 0.0" which is also prescribed
| false in the mapping to a two valued logic. So the entire expression
| (foo? false : false) can be optimized to false.
|
| So yes, NaN escapes my checks, but the it escapes the correct way.
I'm not sure I agree with your reasoning.
The issue is that floating-point comparaison is tree-valued (true,
false, undordered). In case of the NaN case abs(x) should return
'unordered' (not false) -- the fact that it returns false is just an
artifact of implementation to be used in *conjunction* with the
opposite comparaison. Therefore I agree with Toon's reasoning that
your transformation is safe only under -funsafe-math or in the absence
of NaNs.
| [You might also appreciate that "x == x" is a better explicit check
| for finite vs. NaN that would require only a single comparison]
As an aside, I think "x == x" evaluating to true for checking for
finite values vs. NaNs is a common misconception: x == x may trap if x
is a signaling NaN, therefore the comparaison may not yield any value.
-- Gaby
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 9:54 ` Toon Moene
@ 2002-07-21 10:04 ` Roger Sayle
2002-07-21 11:05 ` Gabriel Dos Reis
2002-07-21 11:16 ` Toon Moene
0 siblings, 2 replies; 42+ messages in thread
From: Roger Sayle @ 2002-07-21 10:04 UTC (permalink / raw)
To: Toon Moene; +Cc: gcc-patches
> Now computer hardware is forced to project that three valued logic onto a
> two valued logical "true, false" dichotomy. The solution chosen is to have
> both comparisons above return "false". That means that to check for a NaN
> and use a > or <= comparison, you have to use *both*, else the NaN will
> just escape your check.
When applying a code transformation it is sufficient to guarantee that
the behaviour of the transformed code is the same as the original.
In this case, I don't have to explicitly "check for a NaN" with two
comparisons iff the optimized code produces the same results in the
presence of NaNs and finite values.
Your suggestion of requiring two tests to check for a NaN amounts to
(x<0.0) || (x>=0.0)? finite_case : NaN_case
where finite_case of "abs(x) < 0.0" always returns false, and the
NaN_case "abs(NaN) < 0.0" is "NaN < 0.0" which is also prescribed
false in the mapping to a two valued logic. So the entire expression
(foo? false : false) can be optimized to false.
So yes, NaN escapes my checks, but the it escapes the correct way.
[You might also appreciate that "x == x" is a better explicit check
for finite vs. NaN that would require only a single comparison]
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 9:49 ` Roger Sayle
@ 2002-07-21 9:54 ` Toon Moene
2002-07-21 10:04 ` Roger Sayle
0 siblings, 1 reply; 42+ messages in thread
From: Toon Moene @ 2002-07-21 9:54 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches
Roger Sayle wrote:
> On Sat, 20 Jul 2002, Toon Moene wrote:
> > Roger Sayle wrote:
> > > This patch optimizes expressions of the form "abs(x) < 0.0" and
> > > "float_extend(abs(x)) < 0.0" as always false. Additionally, for
> > > symmetry, it also optimizes "abs(x) >= 0.0" to always true when
> > > x is an integer mode (or a floating point mode with NaNs) or if
> > > "-ffast-math" has been specified.
> > Wow ! Great ! Except that it only works under unsafe math assumptions
> > (abs(NaN) is NaN, which is unordered in comparisons).
> Nope, its always safe. "abs(x) < 0.0" is false under all conditions,
> including the presence of NaNs, infinities and signed zeros. Its
> "abs(x) >= 0.0" that is always true only when the user specifies
> "-ffast-math". You got lucky with "C / R" that the condition appears
> in the RTL the right way around, so that the conditional branches will
> be optimized away with just "-O".
Ah, yes, I already thought that would be your reasoning. Correct to the
letter, but not the spirit :-)
The outcome of comparing a number with NaN is: `unordered', which means
just what it says: There is no sensible answer to the question "is a NaN
greater than or equal to or less than this finite number".
This is three-valued logic:
a > NaN gives "unordered"
a <= NaN gives "unordered"
Now computer hardware is forced to project that three valued logic onto a
two valued logical "true, false" dichotomy. The solution chosen is to have
both comparisons above return "false". That means that to check for a NaN
and use a > or <= comparison, you have to use *both*, else the NaN will
just escape your check.
IOW, your X < 0.0 will return false for the wrong reason if you're not also
testing X >= 0.0. As you don't do that in the code snippet you changed,
your X < 0.0 test (or rather the assumptions in the code following) will be
wrong, *unless* you already assume no NaNs, i.e., are covered by
!HONOR_NANS.
Hope this helps,
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-21 9:08 ` Toon Moene
@ 2002-07-21 9:49 ` Roger Sayle
2002-07-21 9:54 ` Toon Moene
0 siblings, 1 reply; 42+ messages in thread
From: Roger Sayle @ 2002-07-21 9:49 UTC (permalink / raw)
To: Toon Moene; +Cc: gcc-patches
On Sat, 20 Jul 2002, Toon Moene wrote:
> Roger Sayle wrote:
> > This patch optimizes expressions of the form "abs(x) < 0.0" and
> > "float_extend(abs(x)) < 0.0" as always false. Additionally, for
> > symmetry, it also optimizes "abs(x) >= 0.0" to always true when
> > x is an integer mode (or a floating point mode with NaNs) or if
> > "-ffast-math" has been specified.
>
> Wow ! Great ! Except that it only works under unsafe math assumptions
> (abs(NaN) is NaN, which is unordered in comparisons).
Nope, its always safe. "abs(x) < 0.0" is false under all conditions,
including the presence of NaNs, infinities and signed zeros. Its
"abs(x) >= 0.0" that is always true only when the user specifies
"-ffast-math". You got lucky with "C / R" that the condition appears
in the RTL the right way around, so that the conditional branches will
be optimized away with just "-O".
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-20 11:42 Roger Sayle
2002-07-20 15:30 ` Richard Henderson
@ 2002-07-21 9:08 ` Toon Moene
2002-07-21 9:49 ` Roger Sayle
2002-07-22 19:45 ` David Edelsohn
2 siblings, 1 reply; 42+ messages in thread
From: Toon Moene @ 2002-07-21 9:08 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches
Roger Sayle wrote:
> This patch optimizes expressions of the form "abs(x) < 0.0" and
> "float_extend(abs(x)) < 0.0" as always false. Additionally, for
> symmetry, it also optimizes "abs(x) >= 0.0" to always true when
> x is an integer mode (or a floating point mode with NaNs) or if
> "-ffast-math" has been specified.
>
> In addition to the new testcase below, which is optimized on all
> platforms, this patch also has the effect of removing conditional
> branches from division of complex numbers by reals on platforms
> that represent "(set (reg:DF) (const_double:DF 0x0))" explicitly.
Wow ! Great ! Except that it only works under unsafe math assumptions
(abs(NaN) is NaN, which is unordered in comparisons).
Thanks !
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-20 15:30 ` Richard Henderson
@ 2002-07-20 15:39 ` Roger Sayle
0 siblings, 0 replies; 42+ messages in thread
From: Roger Sayle @ 2002-07-20 15:39 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc-patches
On Sat, 20 Jul 2002, Richard Henderson wrote:
> On Sat, Jul 20, 2002 at 12:08:33PM -0600, Roger Sayle wrote:
> > * simplify-rtx.c (simplify_relational_operation): Optimize
> > abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).
> >
> > * gcc.c-torture/execute/20020720-1.c: New test case.
>
> Ok. We'll see how broadly the testcase applied. I could
> see the optimizers getting confused on some platforms.
Many thanks. Commited.
If we encounter any platforms that fail the new testcase, we can
remove it from the testsuite. I thought it better to try to add
a new test, than submit a patch without one.
Many thanks once again.
Roger
--
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH] Optimize abs(x) < 0.0
2002-07-20 11:42 Roger Sayle
@ 2002-07-20 15:30 ` Richard Henderson
2002-07-20 15:39 ` Roger Sayle
2002-07-21 9:08 ` Toon Moene
2002-07-22 19:45 ` David Edelsohn
2 siblings, 1 reply; 42+ messages in thread
From: Richard Henderson @ 2002-07-20 15:30 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc-patches, Toon Moene
On Sat, Jul 20, 2002 at 12:08:33PM -0600, Roger Sayle wrote:
> * simplify-rtx.c (simplify_relational_operation): Optimize
> abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).
>
> * gcc.c-torture/execute/20020720-1.c: New test case.
Ok. We'll see how broadly the testcase applied. I could
see the optimizers getting confused on some platforms.
r~
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH] Optimize abs(x) < 0.0
@ 2002-07-20 11:42 Roger Sayle
2002-07-20 15:30 ` Richard Henderson
` (2 more replies)
0 siblings, 3 replies; 42+ messages in thread
From: Roger Sayle @ 2002-07-20 11:42 UTC (permalink / raw)
To: gcc-patches; +Cc: Toon Moene
This patch optimizes expressions of the form "abs(x) < 0.0" and
"float_extend(abs(x)) < 0.0" as always false. Additionally, for
symmetry, it also optimizes "abs(x) >= 0.0" to always true when
x is an integer mode (or a floating point mode with NaNs) or if
"-ffast-math" has been specified.
In addition to the new testcase below, which is optimized on all
platforms, this patch also has the effect of removing conditional
branches from division of complex numbers by reals on platforms
that represent "(set (reg:DF) (const_double:DF 0x0))" explicitly.
Without this patch, the following FORTRAN example,
COMPLEX FUNCTION CF(C, R)
COMPLEX C
REAL R
CF = C/R
END
generates the following sequence on the alpha:
cf_:
.frame $30,0,$26,0
.prologue 0
lds $f14,0($17)
lds $f13,0($18)
lds $f15,4($17)
cpys $f31,$f13,$f10 <--- ABS
cmptlt $f10,$f31,$f10 <--- COMPARE
fbne $f10,$L2 <--- JUMP
divs $f31,$f13,$f10
muls $f14,$f10,$f12
muls $f10,$f31,$f11
muls $f15,$f10,$f10
subs $f15,$f12,$f12
adds $f11,$f13,$f11
adds $f10,$f14,$f10
$L4:
divs $f12,$f11,$f12
divs $f10,$f11,$f10
sts $f12,4($16)
sts $f10,0($16)
ret $31,($26),1
.align 4
$L2:
divs $f13,$f31,$f10
muls $f15,$f10,$f12
muls $f13,$f10,$f11
muls $f14,$f10,$f10
subs $f12,$f14,$f12
adds $f11,$f31,$f11
adds $f10,$f15,$f10
br $31,$L4
.end cf_
But with this patch, we now generate the shorter and more efficient
cf_:
.frame $30,0,$26,0
.prologue 0
lds $f15,0($17)
lds $f14,0($18)
lds $f12,4($17)
divs $f31,$f14,$f10
muls $f15,$f10,$f13
muls $f10,$f31,$f11
muls $f12,$f10,$f10
subs $f12,$f13,$f12
adds $f11,$f14,$f11
adds $f10,$f15,$f10
divs $f12,$f11,$f12
divs $f10,$f11,$f10
sts $f12,4($16)
cpys $f31,$f31,$f31
sts $f10,0($16)
ret $31,($26),1
.end cf_
This patch has been tested by a complete bootstrap (all languages
except Ada and treelang) and "make -k check" in the gcc directory
on both alphaev67-dec-osf5.1 and i686-pc-linux-gnu with no new
regressions. The libstdc++-v3 and libjava test suites weren't run
due to the current "Program timed out" issues in libjava.
Ok for mainline?
2002-07-20 Roger Sayle <roger@eyesopen.com>
* simplify-rtx.c (simplify_relational_operation): Optimize
abs(x) < 0.0 (and abs(x) >= 0.0 when using -ffast-math).
* gcc.c-torture/execute/20020720-1.c: New test case.
Index: simplify-rtx.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.110
diff -c -3 -p -r1.110 simplify-rtx.c
*** simplify-rtx.c 11 Jul 2002 23:52:59 -0000 1.110
--- simplify-rtx.c 20 Jul 2002 02:54:15 -0000
*************** simplify_relational_operation (code, mod
*** 2075,2080 ****
--- 2075,2102 ----
return const0_rtx;
break;
+ case LT:
+ /* Optimize abs(x) < 0.0. */
+ if (trueop1 == CONST0_RTX (mode))
+ {
+ tem = GET_CODE (trueop0) == FLOAT_EXTEND ? XEXP (trueop0, 0)
+ : trueop0;
+ if (GET_CODE (tem) == ABS)
+ return const0_rtx;
+ }
+ break;
+
+ case GE:
+ /* Optimize abs(x) >= 0.0. */
+ if (trueop1 == CONST0_RTX (mode) && !HONOR_NANS (mode))
+ {
+ tem = GET_CODE (trueop0) == FLOAT_EXTEND ? XEXP (trueop0, 0)
+ : trueop0;
+ if (GET_CODE (tem) == ABS)
+ return const1_rtx;
+ }
+ break;
+
default:
break;
}
*** /dev/null Thu Aug 30 14:30:55 2001
--- gcc.c-torture/execute/20020720-1.c Sat Jul 20 11:04:10 2002
***************
*** 0 ****
--- 1,36 ----
+ /* Copyright (C) 2002 Free Software Foundation.
+
+ Ensure that fabs(x) < 0.0 optimization is working.
+
+ Written by Roger Sayle, 20th July 2002. */
+
+ extern void abort (void);
+ extern double fabs (double);
+ extern void link_error (void);
+
+ void
+ foo (double x)
+ {
+ double p, q;
+
+ p = fabs (x);
+ q = 0.0;
+ if (p < q)
+ link_error ();
+ }
+
+ int
+ main()
+ {
+ foo (1.0);
+ return 0;
+ }
+
+ #ifndef __OPTIMIZE__
+ void
+ link_error ()
+ {
+ abort ();
+ }
+ #endif
+
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2002-07-26 2:56 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-23 16:09 [PATCH] Optimize abs(x) < 0.0 Joern Rennecke
2002-07-23 18:44 ` Roger Sayle
2002-07-23 18:51 ` Andrew Pinski
2002-07-23 19:49 ` Richard Henderson
2002-07-23 20:16 ` Kaveh R. Ghazi
2002-07-23 21:58 ` Roger Sayle
2002-07-23 22:07 ` Kaveh R. Ghazi
2002-07-24 7:47 ` Roger Sayle
2002-07-24 8:25 ` Joern Rennecke
2002-07-24 22:20 ` Roger Sayle
2002-07-25 10:30 ` Richard Henderson
2002-07-25 10:37 ` Bob Wilson
2002-07-25 14:49 ` Roger Sayle
2002-07-25 16:17 ` Richard Henderson
2002-07-25 20:15 ` Roger Sayle
-- strict thread matches above, loose matches on Subject: below --
2002-07-24 11:35 Bob Wilson
2002-07-22 14:09 Brad Lucier
2002-07-22 14:46 ` Gabriel Dos Reis
2002-07-20 11:42 Roger Sayle
2002-07-20 15:30 ` Richard Henderson
2002-07-20 15:39 ` Roger Sayle
2002-07-21 9:08 ` Toon Moene
2002-07-21 9:49 ` Roger Sayle
2002-07-21 9:54 ` Toon Moene
2002-07-21 10:04 ` Roger Sayle
2002-07-21 11:05 ` Gabriel Dos Reis
2002-07-21 11:19 ` Michael Matz
2002-07-21 12:21 ` Gabriel Dos Reis
2002-07-21 15:59 ` Roger Sayle
2002-07-21 16:02 ` Toon Moene
2002-07-21 17:16 ` Gabriel Dos Reis
2002-07-21 19:43 ` Richard Henderson
2002-07-22 0:54 ` Gabriel Dos Reis
2002-07-22 10:18 ` Richard Henderson
2002-07-22 10:24 ` Gabriel Dos Reis
2002-07-22 11:10 ` Richard Henderson
2002-07-22 11:21 ` Gabriel Dos Reis
2002-07-21 11:16 ` Toon Moene
2002-07-21 12:20 ` Gabriel Dos Reis
2002-07-22 19:45 ` David Edelsohn
2002-07-22 19:54 ` Roger Sayle
2002-07-22 20:18 ` David Edelsohn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).