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

[Khem Raj <raj.khem@gmail.com>]

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