[PATCH][RFC] arch-armv7ve.inc: respcet armv7a override as well

[PATCH][RFC] arch-armv7ve.inc: respcet armv7a override as well

[Martin Jansa]

* in all cases we currently have we consider armv7ve to be compatible with armv7a

Signed-off-by: Martin Jansa <Martin.Jansa@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

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

[Martin Jansa]

* in all cases we currently have we consider armv7ve to be compatible with armv7a

Signed-off-by: Martin Jansa <Martin.Jansa@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

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

[Andre McCurdy]

On Fri, Jan 8, 2016 at 4:44 AM, Martin Jansa <martin.jansa@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?

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.

Maybe adding a generic "armv7" over-ride which can be enabled by all
armv7 variants is a better option?

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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Martin Jansa]

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

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

> 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@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@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

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

[Andre McCurdy]

On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa@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@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.

> 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@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@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

[Phil Blundell]

On Fri, 2016-01-08 at 10:24 -0800, Andre McCurdy wrote:
> On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Fri, Jan 08, 2016 at 08:24:36AM -0800, Andre McCurdy wrote:
> >> 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.

Yeah, there clearly is some difference in "closeness".

armv4 and armv5 are at least moderately close, in the sense that an
armv5 processor can run almost all (though not absolutely all) armv4
binaries.  There are some significant differences in code generation
and, in particular, ARMv4 is not supported by the EABI (i.e. binary
libraries compiled with -march=armv4 are not EABI compliant).

armv7a and armv7ve are close to each other in the sense that an armv7ve
processor can run any armv7a binary (i.e. the architecture with
virtualisation extensions is a superset of the one without), and there
are only fairly minor differences in code generation between the two.

armv7a and armv7r are, as far as application code needs to be concerned,
more or less equivalent.  Clearly ARMv7-R cores don't have MMUs, but
this ought to manifest itself in a different TARGET_OS setting and there
should be no particular need for overrides to distinguish armv7r
specifically.

armv7m and armv7a/r are a bit more complicated because, in general, you
can't run an armv7a/r binary on an armv7m processor (which doesn't have
32 bit instructions) and you can't run an armv7m binary on an armv7a
processor (which may not have the divide instruction).  It might be true
to say that armv7ve processors can always run binaries built for armv7m;
I'm not sure.  But whether there are any situations where overrides need
to care is unclear.

But overall I remain fairly convinced that the direction of travel ought
to be towards having fewer overrides, and the ones that we do have being
more semantically meaningful.

p.

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

[Khem Raj]

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


> On Jan 8, 2016, at 10:24 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
> 
> On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa@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@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@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@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 
>> --
>> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

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

[Phil Blundell]

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.

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

> We should strive to reduce this tuning mayhem
> on arm especially.

I agree with this, though.

p.

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

[Khem Raj]

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

Re: [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@gmail.com> wrote:
>
>> On Jan 8, 2016, at 10:24 AM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> On Fri, Jan 8, 2016 at 9:00 AM, Martin Jansa <martin.jansa@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@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@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@lists.openembedded.org
>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>> --
>>> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

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

[Phil Blundell]

On Fri, 2016-01-08 at 08:24 -0800, Andre McCurdy wrote:
> Maybe adding a generic "armv7" over-ride which can be enabled by all
> armv7 variants is a better option?

Maybe, but the time to consider that would be when we discover a
concrete place that it'd be useful. 

To be honest, having seen the existing overrides that you sent patches
for, there are very few cases where an override on _armv7a or any other
specific variant seems unambiguously like the right thing.  For example,
looking at the tree I happen to have lying around here:

- it seems that the valgrind ones have already been established as
spurious;

- the libav FULL_OPTIMIZATION thing also seems fairly spurious. 

- the overrides in gcc-configure-common are basically just trying to
translate TARGET_ARCH back into the appropriate -march flag for gcc, and
it seems faintly silly to require a separate override for every possible
arch setting.  It might be better for the tuning files to define a
specific variable with the -march string in, define CFLAGS in terms of
that, and then just teach gcc's configury to do --with-arch=${GCC_ARCH}
if it's defined.

- the ones in xf86-video-omapfb_git.bb seem to be using armv7a as a
proxy for "this is a particular omap chip" in order to trigger some or
other hack.  Since omapfb is fairly chip-specific anyway this is
probably ok, but it most likely doesn't want perpetuating.

Then there are things like the armv4/armv5 overrides in mailx which are
apparently workarounds for a bug in some or other version of gcc.  The
common thread through most of these seems to be that thumb1 support just
doesn't work very well in gcc and, given that thumb1 is something of a
minority interest nowadays, it's tempting to say that we should not even
try to support it any longer.  But if we did want to keep it around then
defining a specific "thumb1" override that would be set by all thumb1
arches seems like it would be the right short term fix.  In the long
term, clearly, the best plan would be for the folks who still care about
thumb1 to fix gcc.

So, overall, it rather seems to me that we should be trying to get rid
of the majority of these _armvNN overrides, rather than letting them
proliferate into armv7ve and whatever.

p.