[PATCH v2 0/4] fixup armv7a over-rides for armv7ve

[PATCH v2 0/4] fixup armv7a over-rides for armv7ve

[Andre McCurdy]

The _armv7a over-ride is no longer enabled for machines based on
tune-cortexa7.inc and tune-cortexa15.inc. These machines now enable
the _armv7ve over-ride instead.

The preferred solution is to remove the need for any armv7a over-rides,
but where that isn't possible then duplicate armv7a over-rides for
armv7ve.

Note that the qemu.inc change has been dropped from this v2 patch set
since the function of the over-ride and the best approach for armv7ve
isn't clear (QEMU_EXTRAOPTIONS is related to packaging). Since fixing
gcc and valgrind for cortexa15 are much more critical (at least for
me), focus on getting those patches merged first.

Andre McCurdy (4):
  valgrind: don't restrict to armv7a
  gcc-configure-common.inc: duplicate armv7a over-ride for armv7ve
  libav.inc: duplicate armv7a over-rides for armv7ve
  libpostproc: duplicate armv7a over-rides for armv7ve

 meta/recipes-devtools/gcc/gcc-configure-common.inc | 1 +
 meta/recipes-devtools/valgrind/valgrind_3.10.1.bb  | 8 +++++---
 meta/recipes-multimedia/libav/libav.inc            | 2 ++
 meta/recipes-multimedia/libav/libpostproc_git.bb   | 2 ++
 4 files changed, 10 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH v2 1/4] valgrind: don't restrict to armv7a

[Andre McCurdy]

Valgrind has been tested on armv5te/qemuarm, so it seems
that valgrind's configure check for armv7 is over cautious.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/recipes-devtools/valgrind/valgrind_3.10.1.bb | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index c1c11d4..95b3966 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
@@ -32,16 +32,18 @@ SRC_URI = "http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
 SRC_URI[md5sum] = "60ddae962bc79e7c95cfc4667245707f"
 SRC_URI[sha256sum] = "fa253dc26ddb661b6269df58144eff607ea3f76a9bcfe574b0c7726e1dfcb997"
 
-COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
-COMPATIBLE_HOST_armv7a = 'arm.*-linux'
+COMPATIBLE_HOST = '(i.86|x86_64|arm|mips|powerpc|powerpc64).*-linux'
 
 PR = "r1"
 
 inherit autotools ptest
 
 EXTRA_OECONF = "--enable-tls --without-mpicc"
-EXTRA_OECONF_armv7a = "--enable-tls -host=armv7-none-linux-gnueabi --without-mpicc"
 EXTRA_OECONF += "${@['--enable-only32bit','--enable-only64bit'][d.getVar('SITEINFO_BITS', True) != '32']}"
+
+# valgrind checks host_cpu "armv7*)", so we need to over-ride the autotools.bbclass default --host option
+EXTRA_OECONF_append_arm = " --host=armv7${HOST_VENDOR}-${HOST_OS}"
+
 EXTRA_OEMAKE = "-w"
 
 CFLAGS_append_libc-uclibc = " -D__UCLIBC__ "
-- 
1.9.1

[PATCH v2 2/4] gcc-configure-common.inc: duplicate armv7a over-ride for armv7ve

[Andre McCurdy]

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-configure-common.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 45b3f15..84e971a 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -74,6 +74,7 @@ EXTRA_OECONF_append_armv6 = " --with-arch=armv6"
 EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a"
 EXTRA_OECONF_append_armv7m = " --with-arch=armv7-m"
 EXTRA_OECONF_append_armv7r = " --with-arch=armv7-r"
+EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"
 
 EXTRA_OECONF_GCC_FLOAT ??= ""
 CPPFLAGS = ""
-- 
1.9.1

[PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Andre McCurdy]

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/recipes-multimedia/libav/libav.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-multimedia/libav/libav.inc b/meta/recipes-multimedia/libav/libav.inc
index 05b7e87..371e066 100644
--- a/meta/recipes-multimedia/libav/libav.inc
+++ b/meta/recipes-multimedia/libav/libav.inc
@@ -29,9 +29,11 @@ inherit autotools pkgconfig
 B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"
 
 FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
+FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
 BUILD_OPTIMIZATION = "${FULL_OPTIMIZATION}"
 
 EXTRA_FFCONF_armv7a = "--cpu=cortex-a8"
+EXTRA_FFCONF_armv7ve = "--cpu=cortex-a8"
 EXTRA_FFCONF ?= ""
 
 PACKAGECONFIG ??= "avdevice avfilter avplay bzip2 gpl theora x264 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-- 
1.9.1

[PATCH v2 4/4] libpostproc: duplicate armv7a over-rides for armv7ve

[Andre McCurdy]

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
---
 meta/recipes-multimedia/libav/libpostproc_git.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-multimedia/libav/libpostproc_git.bb b/meta/recipes-multimedia/libav/libpostproc_git.bb
index 4aaa50f..911ae86 100644
--- a/meta/recipes-multimedia/libav/libpostproc_git.bb
+++ b/meta/recipes-multimedia/libav/libpostproc_git.bb
@@ -18,9 +18,11 @@ S = "${WORKDIR}/git"
 inherit autotools lib_package pkgconfig
 
 FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
+FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
 BUILD_OPTIMIZATION = "${FULL_OPTIMIZATION}"
 
 EXTRA_FFCONF_armv7a = "--cpu=cortex-a8"
+EXTRA_FFCONF_armv7ve = "--cpu=cortex-a8"
 EXTRA_FFCONF ?= ""
 
 EXTRA_OECONF = " \
-- 
1.9.1

Re: [PATCH v2 2/4] gcc-configure-common.inc: duplicate armv7a over-ride for armv7ve

[Phil Blundell]

On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>  EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a"
>  EXTRA_OECONF_append_armv7m = " --with-arch=armv7-m"
>  EXTRA_OECONF_append_armv7r = " --with-arch=armv7-r"
> +EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"

Please add a comment explaining why this isn't --with-arch=armv7ve.

p.

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Phil Blundell]

On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>  FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
> +FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"

I wonder if this would be better as just FULL_OPTIMIZATION_arm.  That
said, the OPTIMIZATION variables are primarily distro knobs and it's not
entirely clear that individual packages ought to be overriding them at
all.  

Does anybody know whether there is any actual science behind the use of
those flags on armv7a specifically?

p.

Re: [PATCH v2 2/4] gcc-configure-common.inc: duplicate armv7a over-ride for armv7ve

[Andre McCurdy]

On Thu, Jan 7, 2016 at 3:34 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>>  EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a"
>>  EXTRA_OECONF_append_armv7m = " --with-arch=armv7-m"
>>  EXTRA_OECONF_append_armv7r = " --with-arch=armv7-r"
>> +EXTRA_OECONF_append_armv7ve = " --with-arch=armv7-a"
>
> Please add a comment explaining why this isn't --with-arch=armv7ve.

To make it possible to (continue to) share the same gcc-cross etc
binaries between armv7a and armv7ve builds. It's the minimal change to
keep things working as they are now.

The more invasive, but perhaps more correct, change might be to
completely remove these "--with-arch=XXX" options from
gcc-configure-common.inc and replace them with "--with-cpu=XXX"
options in gcc-target.inc ?

> p.
>
>

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Andre McCurdy]

On Thu, Jan 7, 2016 at 3:40 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>>  FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
>> +FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
>
> I wonder if this would be better as just FULL_OPTIMIZATION_arm.  That
> said, the OPTIMIZATION variables are primarily distro knobs and it's not
> entirely clear that individual packages ought to be overriding them at
> all.
>
> Does anybody know whether there is any actual science behind the use of
> those flags on armv7a specifically?

They go back to at least 2011, so whatever science there might have
been back then is likely invalid by now.

  http://git.openembedded.org/meta-openembedded/commit/?id=61e4b696de080545e6ffe80d28a9c6ef8990695a

> p.
>
>

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Khem Raj]

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


> On Jan 7, 2016, at 3:40 PM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>> FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
>> +FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit-frame-pointer -O4 -ffast-math"
> 

O4 ? may be just replace this whole thing with -Ofast now a days
-fexpensive-optimizations is enabled at -O2,-O3 anyway same for fomit-frame-pointer and -Ofast turns on
feast-match on top of -O3

> I wonder if this would be better as just FULL_OPTIMIZATION_arm.  That
> said, the OPTIMIZATION variables are primarily distro knobs and it's not
> entirely clear that individual packages ought to be overriding them at
> all.
> 
> Does anybody know whether there is any actual science behind the use of
> those flags on armv7a specifically?

it came into ffmpeg circa 2008 and proliferated into related components primarily to support vectorization and neon
which was quite nascent for ARM architecture in those days in gcc. Today if you were to configure libav with default options
then it uses mainly -fomit-frame-pointer-O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize

which is primarily -Ofast -fno-tree-vectorize
> 
> p.
> 
> 
> --
> _______________________________________________
> 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: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Richard Purdie]

On Mon, 2016-01-11 at 14:58 -0800, Khem Raj wrote:
> > On Jan 7, 2016, at 3:40 PM, Phil Blundell <pb@pbcl.net> wrote:
> > 
> > On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
> > > FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit
> > > -frame-pointer -O4 -ffast-math"
> > > +FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit
> > > -frame-pointer -O4 -ffast-math"
> > 
> 
> O4 ? may be just replace this whole thing with -Ofast now a days
> -fexpensive-optimizations is enabled at -O2,-O3 anyway same for fomit
> -frame-pointer and -Ofast turns on
> feast-match on top of -O3
> 
> > I wonder if this would be better as just FULL_OPTIMIZATION_arm. 
> >  That
> > said, the OPTIMIZATION variables are primarily distro knobs and
> > it's not
> > entirely clear that individual packages ought to be overriding them
> > at
> > all.
> > 
> > Does anybody know whether there is any actual science behind the
> > use of
> > those flags on armv7a specifically?
> 
> it came into ffmpeg circa 2008 and proliferated into related
> components primarily to support vectorization and neon
> which was quite nascent for ARM architecture in those days in gcc.
> Today if you were to configure libav with default options
> then it uses mainly -fomit-frame-pointer-O3 -fno-math-errno -fno
> -signed-zeros -fno-tree-vectorize
> 
> which is primarily -Ofast -fno-tree-vectorize

I have to admit that my personal instinct on these is simply to remove
them. I doubt they're buying much now and if people really want to tune
specific recipes by hand they still can do so from their local/distro
config.

Cheers,

Richard

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Khem Raj]

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


> On Jan 11, 2016, at 3:07 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Mon, 2016-01-11 at 14:58 -0800, Khem Raj wrote:
>>> On Jan 7, 2016, at 3:40 PM, Phil Blundell <pb@pbcl.net> wrote:
>>> 
>>> On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>>>> FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit
>>>> -frame-pointer -O4 -ffast-math"
>>>> +FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit
>>>> -frame-pointer -O4 -ffast-math"
>>> 
>> 
>> O4 ? may be just replace this whole thing with -Ofast now a days
>> -fexpensive-optimizations is enabled at -O2,-O3 anyway same for fomit
>> -frame-pointer and -Ofast turns on
>> feast-match on top of -O3
>> 
>>> I wonder if this would be better as just FULL_OPTIMIZATION_arm.
>>> That
>>> said, the OPTIMIZATION variables are primarily distro knobs and
>>> it's not
>>> entirely clear that individual packages ought to be overriding them
>>> at
>>> all.
>>> 
>>> Does anybody know whether there is any actual science behind the
>>> use of
>>> those flags on armv7a specifically?
>> 
>> it came into ffmpeg circa 2008 and proliferated into related
>> components primarily to support vectorization and neon
>> which was quite nascent for ARM architecture in those days in gcc.
>> Today if you were to configure libav with default options
>> then it uses mainly -fomit-frame-pointer-O3 -fno-math-errno -fno
>> -signed-zeros -fno-tree-vectorize
>> 
>> which is primarily -Ofast -fno-tree-vectorize
> 
> I have to admit that my personal instinct on these is simply to remove
> them. I doubt they're buying much now and if people really want to tune
> specific recipes by hand they still can do so from their local/distro
> config.

Thats ok, however the most tested option combination seems to use -O3 since
thats configure’s default for libav
If we start using -O2 .. as we use that for global optimizations in OE
then we are odd man out.

> 
> Cheers,
> 
> Richard
> 


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

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Andre McCurdy]

On Mon, Jan 11, 2016 at 3:07 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2016-01-11 at 14:58 -0800, Khem Raj wrote:
>> > On Jan 7, 2016, at 3:40 PM, Phil Blundell <pb@pbcl.net> wrote:
>> >
>> > On Thu, 2016-01-07 at 14:29 -0800, Andre McCurdy wrote:
>> > > FULL_OPTIMIZATION_armv7a = "-fexpensive-optimizations -fomit
>> > > -frame-pointer -O4 -ffast-math"
>> > > +FULL_OPTIMIZATION_armv7ve = "-fexpensive-optimizations -fomit
>> > > -frame-pointer -O4 -ffast-math"
>>
>> O4 ? may be just replace this whole thing with -Ofast now a days
>> -fexpensive-optimizations is enabled at -O2,-O3 anyway same for fomit
>> -frame-pointer and -Ofast turns on
>> feast-match on top of -O3
>>
>> > I wonder if this would be better as just FULL_OPTIMIZATION_arm.
>> >  That
>> > said, the OPTIMIZATION variables are primarily distro knobs and
>> > it's not
>> > entirely clear that individual packages ought to be overriding them
>> > at
>> > all.
>> >
>> > Does anybody know whether there is any actual science behind the
>> > use of
>> > those flags on armv7a specifically?
>>
>> it came into ffmpeg circa 2008 and proliferated into related
>> components primarily to support vectorization and neon
>> which was quite nascent for ARM architecture in those days in gcc.
>> Today if you were to configure libav with default options
>> then it uses mainly -fomit-frame-pointer-O3 -fno-math-errno -fno
>> -signed-zeros -fno-tree-vectorize
>>
>> which is primarily -Ofast -fno-tree-vectorize
>
> I have to admit that my personal instinct on these is simply to remove
> them. I doubt they're buying much now and if people really want to tune
> specific recipes by hand they still can do so from their local/distro
> config.

It's the other armv7a over-ride which probably needs more careful
consideration, ie:

  EXTRA_FFCONF_armv7a = "--cpu=cortex-a8"

Khem, did you look into that? What happens to libav if we don't
configure for a suitable CPU?


> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Phil Blundell]

On Mon, 2016-01-11 at 14:58 -0800, Khem Raj wrote:
> it came into ffmpeg circa 2008 and proliferated into related components primarily to support vectorization and neon
> which was quite nascent for ARM architecture in those days in gcc. Today if you were to configure libav with default options
> then it uses mainly -fomit-frame-pointer-O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize
> 
> which is primarily -Ofast -fno-tree-vectorize

I think -fno-tree-vectorize is just there as a workaround for old
compilers.  It sounds like you're saying that ffmpeg basically just
wants "-Ofast", and by implication it wants this on all architectures.
So in that case there is no need for a FULL_OPTIMIZATION override on
arm, let alone armv7a specifically.

Whether ffmpeg ought to be forcing its own FULL_OPTIMIZATION at all
versus leaving it up to the distro is another question.  Personally I
think that individual recipes have no business setting those variables,
and ffmpeg is no exception, but I don't have a particularly strong
opinion either way.

p.

Re: [PATCH v2 3/4] libav.inc: duplicate armv7a over-rides for armv7ve

[Khem Raj]

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


> On Jan 12, 2016, at 1:42 AM, Phil Blundell <pb@pbcl.net> wrote:
> 
> On Mon, 2016-01-11 at 14:58 -0800, Khem Raj wrote:
>> it came into ffmpeg circa 2008 and proliferated into related components primarily to support vectorization and neon
>> which was quite nascent for ARM architecture in those days in gcc. Today if you were to configure libav with default options
>> then it uses mainly -fomit-frame-pointer-O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize
>> 
>> which is primarily -Ofast -fno-tree-vectorize
> 
> I think -fno-tree-vectorize is just there as a workaround for old
> compilers.  It sounds like you're saying that ffmpeg basically just
> wants "-Ofast", and by implication it wants this on all architectures.
> So in that case there is no need for a FULL_OPTIMIZATION override on
> arm, let alone armv7a specifically.

yes I think it should use -Ofast irrespective of architecture.

> 
> Whether ffmpeg ought to be forcing its own FULL_OPTIMIZATION at all
> versus leaving it up to the distro is another question.  Personally I
> think that individual recipes have no business setting those variables,
> and ffmpeg is no exception, but I don't have a particularly strong
> opinion either way.
> 
> p.
> 
> 


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