This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, i386]: AMD btver2 enablement
- From: Jakub Jelinek <jakub at redhat dot com>
- To: venkataramanan dot kumar at amd dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 20 Jul 2012 19:01:04 +0200
- Subject: Re: [PATCH, i386]: AMD btver2 enablement
- References: <20120720163932.29552.15178.sendpatchset@adcelk01.amd.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 20, 2012 at 11:39:32AM -0500, venkataramanan.kumar@amd.com wrote:
> Below patch does the basic enablement for next generation AMD low power btver2 core.
> It defines -march=btver2 and -mtune=btver2, and lets -march=native correctly
> recognizes btver2. At the moment the tuning is mostly a copy of btver1.
> The patch passed bootstrap and the x86 tests.
>
> Is it OK to commit to trunk?
>
> Also can I modify doc/invoke.texi now?
Seems the only difference from btver1 are the cache sizes, right? That
looks very expensive way of adding another cache size, we can only have
32 different schedulings as PROCESSOR_* is used as a bitmask.
For -march=native, it is either no changes or just some small driver-i386.c
tweaks needed to make sure that for this CPU -mtune=btver1 would be used
together with --param l2-cache-size=whatever, or perhaps -mtune=btver2
could be handled just as an alias of -mtune=btver1 plus --param
l2-cache-size=512? Having lots of copy&paste tuning in the compiler
doesn't look like a good idea to me.
Of course unless you plan significant scheduling tweaks for the CPU in the
near future.
Jakub