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

Andre McCurdy
2016-01-11T23:18:18Z

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