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

[Andre McCurdy]

On Mon, Jan 11, 2016 at 11:10 AM, Khem Raj <raj.khem at gmail.com> wrote:
>
>> 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.

armv7ve basically adds integer division instructions to armv7a. It
would be difficult to characterise which apps really benefit from
that.

I agree that tuning options for ARM have turned into mayhem, but it's
more down to supporting nonsense configurations like "an armv7a CPU
without thumb" than it is about armv7ve.

Part of the mayhem also comes from DEFAULTTUNE being over-loaded. It's
used to encode not only CPU features (ISA level, neon -vs- no-neon,
vfpv3 -vs- vfpv4, d16 -vs- d32, big -vs- little endian, etc) but also
distro features which have no business being selected by a machine
config (hf -vs- softfp). That over-loading of DEFAULTTUNE with distro
options isn't specific to ARM though (x86-64 uses DEFAULTTUNE to
select between x32 and the regular ABI), so it's going to take more
effort to fix.


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