[OE-core] [PATCH 4/5] tune-atom.inc: include tune-bonnell.inc instead of tune-core2.inc

[Andre McCurdy]

On Tue, Oct 20, 2015 at 2:16 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Mon, 2015-10-19 at 11:59 -0700, Andre McCurdy wrote:
>> Use 'atom' as an alias for the first generation Intel Atom CPUs.
>> ---
>>  meta/conf/machine/include/tune-atom.inc | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/conf/machine/include/tune-atom.inc b/meta/conf/machine/include/tune-atom.inc
>> index 5e1bb74..24cd676 100644
>> --- a/meta/conf/machine/include/tune-atom.inc
>> +++ b/meta/conf/machine/include/tune-atom.inc
>> @@ -1,2 +1,2 @@
>> -# Atom tunings are the same as core2 for now...
>> -require conf/machine/include/tune-core2.inc
>> +# Alias for the first generation of Intel Atom CPUs.
>> +require conf/machine/include/tune-bonnell.inc
>
> This is actually pretty nasty to anyone who uses package feeds or
> packages since all of a sudden, the system rebuilds with a completely
> different package architecture. Not sure we can take this change for
> that reason.

OK. I was thinking the comment in tune-atom.inc "Atom tunings are the
same as core2 FOR NOW..." gave people fair warning that tune-atom.inc
might not remain an alias for tune-core2.inc forever, but no problem
to drop this patch.

Another approach might be to drop tune-atom.inc altogether. Atom is
now ambiguous in terms of defining a CPU architecture and it hasn't
been a documented gcc x86 tuning option since gcc 4.8

  https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options
  https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options
  https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/x86-Options.html#x86-Options

> I'd also like to understand how much of a difference these specific
> tunes actually give. I know the Intel people have been trying to focus
> on a smaller number of tunes that work well on the majority of platforms
> rather than micro optimising the tunes.
>
> Are there some benchmark numbers or other analysis which shows these
> tunes as being more effective?

Not that I'm aware of. My own tests suggest that the benefits of
bonnell -vs- core2 tuning on a first generation Atom are pretty
unspectacular (maybe ~0 to 5 % performance increase and ~5% increase
in code size). I don't have a Silvermont board. This patch set was
more about enabling further experiments though, so if solid benchmark
improvements are a prerequisite then this patch set isn't ready to
merge.

>
> Cheers,
>
> Richard
>
>
>