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

[Khem Raj]

> On Jan 8, 2016, at 10:24 AM, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
> On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
>> On Fri, Jan 08, 2016 at 08:24:36AM -0800, Andre McCurdy wrote:
>>> On Fri, Jan 8, 2016 at 4:44 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
>>>> * in all cases we currently have we consider armv7ve to be compatible with armv7a
>>> 
>>> Is this a short term workaround or a long term solution?
>> 
>> It's just RFC for discussion.
>> 
>>> If it's a long term solution then how will armv7m and armv7r be
>>> handled? They are likely to need to duplicate a lot of the current
>>> armv7a over-rides too.
>> 
>> armv7a and armv7ve are much closer than armv7a and armv7m or armv7r as
>> Khem said in earlier discussion.
> 
> I'm not sure what the definition of "close" is here. An armv7a CPU can
> not run armv7ve binaries.
> 
> Saying armv7a and armv7ve are close is like saying armv4 and armv5 are
> close. True in some respects, but they don't define each other's
> over-rides.

What I was trying to say is that code generated for ARMv7a would run just fine on armv7ve while
ISAs were not incremental between m and r variants.

So I was asking was what improvements do we get if we choose armv7ve as tune
and I did not get any definitive answers. Why shouldnt we keep using armv7-a
and tune the handful of apps to armv7ve where it is required. In this case it becomes
less attractive to add yet another tune. We should strive to reduce this tuning mayhem
on arm especially.


> 
>> And maybe it's because fewer people use
>> armv7[rm], but currently these 2 aren't used anywhere as overrides (in
>> layers I've in world builds).
>> 
>>> Maybe adding a generic "armv7" over-ride which can be enabled by all
>>> armv7 variants is a better option?
>> 
>> Maybe, but that will change how armv7r and armv7m are currently built, I
>> cannot say if for better or worse, I don't use either.
> 
> I doubt that armv7m or armv7r are buildable at all. Perhaps we should
> drop the tune-cortexm1.inc, tune-cortexm3.inc and tune-cortexr4.inc
> files completely and stop pretending that they might work?
> 
>>> Either way, I'd like to continue cleaning up of the existing armv7a
>>> over-rides (e.g. the libav armv7a specific optimisation is likely
>>> bogus and should be removed, etc).
>>> 
>>> 
>>>> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
>>>> ---
>>>> meta/conf/machine/include/arm/arch-armv7ve.inc | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/meta/conf/machine/include/arm/arch-armv7ve.inc b/meta/conf/machine/include/arm/arch-armv7ve.inc
>>>> index 79e1ef6..d0fdff7 100644
>>>> --- a/meta/conf/machine/include/arm/arch-armv7ve.inc
>>>> +++ b/meta/conf/machine/include/arm/arch-armv7ve.inc
>>>> @@ -3,7 +3,8 @@ DEFAULTTUNE ?= "armv7ve"
>>>> TUNEVALID[armv7ve] = "Enable instructions for ARMv7ve"
>>>> TUNECONFLICTS[armv7ve] = "armv4 armv5 armv6 armv7 armv7a"
>>>> TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', ' -march=armv7ve', '', d)}"
>>>> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:', '' ,d)}"
>>>> +# In all cases we currently have we consider armv7ve to be compatible with armv7a
>>>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv7ve', 'armv7ve:armv7a:', '' ,d)}"
>>>> 
>>>> require conf/machine/include/arm/arch-armv6.inc
>>>> require conf/machine/include/arm/feature-arm-neon.inc
>>>> --
>>>> 2.7.0
>>>> 
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 
>> --
>> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160111/823b9165/attachment-0002.sig>