[OE-core] [PATCH] tune-i686: Add new tune for better support of 686-class CPUs.

[Carlos Alberto Lopez Perez]

On 11/01/18 11:29, Richard Purdie wrote:
> On Thu, 2018-01-11 at 05:08 +0100, Carlos Alberto Lopez Perez wrote:
>> There isn't currently any tune available for i686 x86 optimizations.
>> The tune for i586 doesn't enable i686 specific optimizations, and the
>> one for core2 enables things that won't work on a i686 CPU (like
>> SSE3).
>>
>> This patch also changes the default tune for the qemux86 machine from
>> i586 to i686. This should cause no issue, as "runqemu qemux86"
>> already
>> defaults to run with "-cpu pentium2".
>>
>> The tune for core2 now inherits from this one, which allows to remove
>> the override on the X86ARCH32 definition.
>>
>> Signed-off-by: Carlos Alberto Lopez Perez <clopez at igalia.com>
>> ---
>>  meta/conf/machine/include/tune-core2.inc |  7 ++-----
>>  meta/conf/machine/include/tune-i686.inc  | 25
>> +++++++++++++++++++++++++
>>  meta/conf/machine/qemux86.conf           |  2 +-
>>  3 files changed, 28 insertions(+), 6 deletions(-)
>>  create mode 100644 meta/conf/machine/include/tune-i686.inc
> 
> Please don't do multiple things in a single commit like this.
> 
> The qemux86 default tune change isn't as simple as it might first
> appear as it changes the output artefacts which may or may not mean
> changes to the testing infrastructure (I'd hope not but I also know the
> reality).
> 
> Adding the tune itself should be more straightforward.
> > We do need to keep track of the comment "Set x86 target arch to i686,
> so that glibc enables SSE optimised memcpy, etc." as i586 verses i686
> does make a significant difference to the glibc config.
> 

Sure, I will keep track of the comment. I'll follow-up with a new patch.

Due to this significant difference in performance for glibc, it seems to
me it is worth to try the change on the default tune on qemux68 machine.
Hopefully it will speed-up a bit the testing times both on the testing
architecture and the developer machines.
Will splitting the patch in two will help with this?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180111/0999cf1e/attachment-0002.sig>