[BENCHMARK] runtime impact of fix for target/17390 on i386 targets

[Uros Bizjak <uros dot bizjak at kss-loka dot si>]

Quoting steven at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>:

> ------- Comment #5 from steven at gcc dot gnu dot org  2005-10-19 13:13
> -------
> That patch is yet another example of why we constantly keep having compile
> time
> problems.  Just add more, and more, and more, and more.  And act surprised
> when
> someone notices that gcc 4.1 is four times as slow as 2.95.3 for very little
> benefit on x86 at least.
> 
> Why a new pass over all insns, instead of e.g. teaching postreload cse or
> postreload gcse about this kind of thing?

  The problem is in funny i387 compare FP sequences, that are implemented by a
sequence of AX setting compare and CC setting test before jump insn.

I would like to show the compile time and runtime impact of this patch:

compiling povray-3.6.1 source directory without patch where
CXXFLAGS =  -Wno-multichar -march=i586 -mtune=i686 -O3 -D__NO_MATH_INLINES
-ffast-math -malign-double -minline-all-stringops 

I got following times:

1m37.986
1m37.139
1m38.410

And _with_ patch:

1m37.264
1m37.352
1m37.383

I would say that the difference is burried in noise.

The runtime impact (./povray -display=NONE abyss.pov)

without patch (compile flags as above):
0m16.035
0m16.006
0m15.998
========
0m16.013

And with patch (compile flags as above):
0m14.551
0m14.543
0m14.566
========
0m14.553

Yes, when povray-3.6.1 is compiled with patched gcc-4.1, it is slightly more
than 10% (!!!) faster, which is by far the best result I've ever seen here.

In both cases, gcc was patched with a patch for recip problems
(http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00687.html), that fix PR/23948 and
PR/24123 and is a _MUST_ for any -ffast-math compilation.

Any comment on these numbers?

Uros.