This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tuning gcc for Intel Core2
On Tue, Nov 14, 2006 at 10:07:54AM -0500, Vladimir Makarov wrote:
> H.J., I don't pretend that the code is final. I will be glad if people
> find a better tuning. I did this tuning because it was needed for my
> work. That is strange situation we have no tuning for major processor
> which is available public for a few months. Ideally tunning should be
> availiable before the processor became available to public (that is what
> IBM is doing this for their power6 now). Unfortunately only Intel can
> make it because they do microacrhitecture documentation public too late.
> For example, I started the work long before the documenation was made
> public (a few days ago) using unjustified different information from
As you have discovered, -mtune=generic isn't too bad for Core 2.
> And the patch is useful even if I get the same score because as I wrote
> the code is smaller.
> >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?
> It is the same as generic (may be a bit better).
Can you turn on x86_rep_movl_optimal for -mtune=generic to see what
it does for SPEC CPU 2K on both 32bit and 64bit?
> Here, the results with -m32 as you asked on the mainline few days ago.
> The code is smaller and Int score is a bit better (not because of gcc
> which is actually 0.4% worse)
> base: -O2 -m32 -mtune=generic
> peak: -O2 -m32 -mtune=core2
> Est. SPECint_base2000 1832
> Est. SPECint2000 1843
> Est. SPECfp_base2000 1479
> Est. SPECfp2000 1477