Re: [PATCHv2][RFC] arch-armv7ve.inc: respect armv7a override as well

[Khem Raj <raj.khem@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]


> On Jan 11, 2016, at 11:52 AM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Mon, 2016-01-11 at 11:10 -0800, Khem Raj wrote:
>> So I was asking was what improvements do we get if we choose armv7ve as tune
>> and I did not get any definitive answers.
> 
> If you compile with -march=armv7ve then you get the integer divide
> instructions, which are not enabled under -march=armv7a.

ah idiv. I was just thinking its few virt and security
extensions that may not be used in instruction schedule by gcc but idiv certainly
will be used.

> 
>> Why shouldnt we keep using armv7-a and tune the handful of apps to
>> armv7ve where it is required.
> 
> That'd be a distro decision.  I agree that if you are targetting a mix
> of cores, some that have hardware div and some that don't, it may not be
> sensible to compile everything twice and you might want to standardise
> on armv7a as the least common denominator.  But Cortex-A15 is
> widespread, and I think people who select tune-cortexa15.inc would have
> a reasonable expectation that it would, indeed, tune for the
> instructions that their processor supports.  That's not to say that it
> necessarily needs to be a generic armv7ve tune of course.

I am with you for a15.

> 
>> We should strive to reduce this tuning mayhem
>> on arm especially.
> 
> I agree with this, though.
> 
> p.
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]