GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004

[Paolo Bonzini]

> It looks that gcc does not detect that parameters to sin() and cos() are 
> actually the same.

Yes, because they are converted to jumps too early.  You could paper 
over it in this case, by disabling the call to gimplify_minimax_expr in 
gimplify.c.  The results of the attached patch, with -O2 -ffast-math, 
are as follows:

prova.c:
	#define __NO_MATH_INLINES
	#include <math.h>
	#define PI2 0x1.922p0

	double dv (double x)
	{
	  return 2.0 * sin (((x < PI2) ? x : PI2))
		* cos (((x < PI2) ? x : PI2));
	}

prova.c.t59.optimized:
	dv (x)
	{
	  double T.1;
	
	<bb 0>:
	  T.1 = MIN_EXPR <x, 1.57080078125e+0>;
	  return sin (T.1) * cos (T.1) * 2.0e+0;
	}

prova.s:
	dv:
		pushl	%ebp
		flds	.LC0
		movl	%esp, %ebp
		fldl	8(%ebp)
		fcom	%st(1)
		fnstsw	%ax
		testb	$69, %ah
		jne	.L4
		fstp	%st(0)
		jmp	.L2
	.L4:
		fstp	%st(1)
	.L2:
		fsincos
		leave
		fmulp	%st, %st(1)
		fadd	%st(0), %st
		ret

Now look at prova.s with -march=i686 -mtune=i686 -fomit-frame-pointer:

	dv:
		fldl	4(%esp)
		flds	.LC0
		fcomi	%st(1), %st
		fcmovnb	%st(1), %st
		fstp	%st(1)
		fsincos
		fmulp	%st, %st(1)
		fadd	%st(0), %st
		ret

Now one *would* think that GCC was optimized specially for this 
benchmark! :-)

I don't know why MIN_EXPR and MAX_EXPR were left out of GIMPLE given 
that ABS_EXPR is there.  But these jump threadings seem to be difficult, 
so maybe it is worth including into GIMPLE a COND_EXPR with cmov 
semantics.  Even when if statements are used in the source code, phiopt 
could synthesize it pretty easily.

Paolo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: no-gimplify-minimax.patch
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040818/e3233595/attachment.ksh>