This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tuning gcc for Intel Core2
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, jh at suse dot cz
- Date: Mon, 13 Nov 2006 22:27:18 -0800
- Subject: Re: [patch] tuning gcc for Intel Core2
- References: <4558A4DD.email@example.com>
On Mon, Nov 13, 2006 at 12:01:17PM -0500, Vladimir Makarov wrote:
> Here is the patch for tuning gcc for Intel Core2 processor. I did
> about 30 SPEC2000 runs to find good parameters which are practically
> the same what Intel gave and recommended in their optimization guide
> made public a few days ago.
> The patch increases SPECINT2000 score to 1963 from 1925 (for
> generic) or 1901 (for nocona). SPECFP2000 sore is the same as for
> generic 1875 (nocona has 1856). One benchmark (gcc) did particular
> well -- about 20% improvement (1788 for generic tuning vs 2210 for
> core2). The size of code generated for Core2 is smaller (0.46% for
> SPECInt and 0.54% SPECFp) than one for generic.
This patch is the first step for Core 2 optimization. But I am afraid
that it isn't very useful. I compared -mtune=generic and -mtune=core2
on Core 2. Tha main difference is in 176.gcc. What this patch does is
to turn on
for Core 2, which will avoid external calls to memset. There
are known serious performance problems with x86-64 memory functions,
especially on Core 2. We are working on improving x86-64 memory
functions. A better external memset can improve gcc in SPEC CPU 2K by
more than 20%.
BTW, when Jan and I were working on -mtune=generic, we determined that
turning on x86_rep_movl_optimal wasn't a good idea. What do you get
if you turn off x86_rep_movl_optimal?