This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC viciously beaten by ICC in trig test!
- From: Scott Robert Ladd <coyote at coyotegulch dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 14 Mar 2004 21:26:33 -0500
- Subject: Re: GCC viciously beaten by ICC in trig test!
- References: <Pine.LNX.4.44.0403141713460.12909-100000@www.eyesopen.com>
Roger Sayle wrote:
Consider the following:
#include <math.h>
double doit(double a) { return sin(a) * sin(a); }
Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
significantly slower than Intel's compiler output. However,
commenting out the "#include <math.h>" corrects the situation and GCC
can then generate *exactly* the same sequence as icc.
Wonderful! This is *exactly* the insight I was looking for...
The issue is that glibc's headers provide inline implementations for
sin and cos, and thereby override all of GCC's internal builtin
processing.
I should have thought of this; I've had some past problems with glibc
headers causing problems in my code.
Once this is done, there's nothing tree-ssa, the middle-end or the
i386 can do to improve the code. If GCC is to have a hope of using
"sincos" or SSE2 specific instruction sequences, the "best
intentions" of glibc's headers (will) have to be neutralized first.
Perhaps fixincludes :>
Sometimes, I wonder if GCC should ship its own Standard C library, just
as it ships a Standard C++ template library. However, I suspect the
suggesting such a move might be a bit controversial... ;)
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing