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

Khem Raj
2016-01-11T23:18:21Z

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