RE: [PATCH, i386]: AMD btver2 enablement

["Kumar, Venkataramanan" <Venkataramanan dot Kumar at amd dot com>]

Hi Jakub,

Thanks for reviewing the patch.

> 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.

We are expecting some changes to tunings and costs. We will update them in near future.
There are ISA changes as well like btver2 supports AVX, BMI.

This patch is a first placeholder and additional changes are still to be applied.

> 
> Of course unless you plan significant scheduling tweaks for the CPU in the
> near future.
>

Yes we want to add scheduler descriptions and latency information in near future.

 
Regards,
Venkat.

> -----Original Message-----
> From: Jakub Jelinek [mailto:jakub@redhat.com]
> Sent: Friday, July 20, 2012 10:31 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, i386]: AMD btver2 enablement
> 
> 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