Re: [PATCH] FP operation costs for x86

[Jan Hubicka <jh at suse dot cz>]

> 
> I was recently surprised to discover that the following code
> is not being optimized by GCC mainline on i686-pc-linux-gnu:
> 
> double foo()
> {
>   double x = 2.0;
>   return x + 1.0;
> }
> 
> This is a regression from gcc 3.2.  In fact, GCC does consider
> returning the constant 3.0, but the i386 backend considers the
> double constant more expensive than the floating point addition.
> Indeed the i386 backend considers calling sqrt cheaper than
> evaluating it at compile time.
> 
> The regression was innocently caused by Richard Henderson's
> patch "use narrow fp constants" from 12th May 2002.
> http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00998.html

Good catch ;)
> 
> The problem is that in order to prefer "float" constants over
> "double" constants, this change increased the cost of floating
> point constants greater than COSTS_N_INSNS(1), the default
> RTX cost of an instruction.  The real mystery is that the i386
> backend has never specified the costs of floating point operations
> and so always assumed that any floating point operation was as
> fast as an integer addition, or took the same number of cycles
> as its integer equivalent.

This is because backend never replace FP operations by integer one so it
never compare those two worlds.  It has been safe to assume that all
operations are approximately equally long as there is not much place for
improvement eighter.   However making loads more expensive than
operations broke this.
> 
> 		FADD	FSUB	FMULT	FDIV	FABS	FCHS	FSQRT
> size		2	2	2	2	2	2	2
> i386		23	23	27	88	22	24	122
> i486		8	8	16	73	3	6	85
> pentium		3	3	3	39	1	1	70
> pentiumpro	3	3	5	56	3	3	56
> k6		2	2	2	56	2	2	56
> athlon		4	4	4	24	2	2	35
> pentium4	5	5	7	43	2	2	43

Yes, this is correct from what I remember.
> 
> These values were either found in Intel or AMD technical documentation,
> random WWW searches or the DFA descriptions of the processors in GCC's
> source code.  Follow up patches to refine these values are welcome.
> 
> This patch has been tested with a complete "make bootstrap" and "make
> -k check", all languages except Ada and treelang, on i686-pc-linux-gnu
> with no new regressions.  I've also checked by hand that the testcase
> above is now optimized to "return 3.0".
> 
> 
> Ok for mainline?
Hope Richard will approve it soon.  I guess it can well avoid some of
the perofmrance regressions we have in SPECFP tests.

Honza