[FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on ≥4.9

James Almer jamrial at gmail.com
Mon May 9 03:40:10 CEST 2016


On 5/8/2016 9:58 PM, Michael Niedermayer wrote:
> On Sun, May 08, 2016 at 02:55:13PM -0300, James Almer wrote:
>> On 5/8/2016 10:44 AM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Fri, May 6, 2016 at 8:02 PM, James Almer <jamrial at gmail.com> wrote:
>>>
>>>> On 5/6/2016 8:48 PM, Timothy Gu wrote:
>>>>> On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
>>>>>>
>>>>>> Just to document it, this has caused build breakage in various
>>>>>> scenarios, even in GCC 5.3 (6.1 not tested).
>>>>>>
>>>>>> The latest reported on IRC just today here:
>>>>>> libavcodec/sbrdsp.c: In function 'sbr_neg_odd_64_c':
>>>>>> libavcodec/sbrdsp.c:47:13: internal compiler error: in
>>>>>> vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
>>>>>>  static void sbr_neg_odd_64_c(float *x)
>>>>>>
>>>>>> There are various other cases which usually involve inline asm when
>>>>>> building with SIMD (ie. --cpu=host) and the optimizer running out of
>>>>>> registers, for example:
>>>>>> libavcodec/x86/cabac.h:192:5: error: 'asm' operand has impossible
>>>> constraints
>>>>>>
>>>>>> IMHO this feature is not quite ready to be enabled unconditionally in
>>>>>> our code base, and we should re-evaluate this change.
>>>>>
>>>>> I don't have a problem with reverting this commit, but as James
>>>> mentioned I do
>>>>> prefer the bug to be reported to GCC if possible.
>>>>>
>>>>> Have you also considered the possibility to enable this feature only if
>>>> inline
>>>>> assembly is not enabled?
>>>>
>>>> Nobody disables inline asm when using GCC, so it'd be the same as removing
>>>> tree
>>>> vectorization altogether to begin with.
>>>>
>>>> This feature gives some nice speed boost on parts of the code that don't
>>>> have
>>>> hand written asm, so I'd very much rather keep it and try to get GCC to
>>>> fix bugs
>>>> on their compilers.
>>>
>>>
>>> Which codepaths are sped up _specifically_? If there's anything where it's
>>> significant and important, we can hand-write assembly for it.
>>>
>>> Ronald
>>
>> I don't recall exactly which, but i remember it was audio dsp functions mostly,
>> back when i tested when this feature was introduced.
>> None that we can't write for that matter, just that nobody will ever write
>> because they are either not really important, or interesting, or easy to write.
>> I also remember Ubitux pointed a boost in some code he was working with some
>> time ago when he suggested to enable this feature, but that ultimately didn't
>> happen.
>>
>> Don't hold this as a valid argument against removing the feature since i don't
>> really care enough to go and bench a bunch of functions all over again to bring
>> proof. But if people want to remove it then it would be better to point what
>> parts of the code are being miscompiled and ideally a way to reproduce it,
> 
>> seeing that FATE hasn't complained ever since we introduced this. It would at
>> least give us something to report these issues to gcc's bug tracker.
> 
> there where failures with some gcc versions recetly on fate that
> disappesred when the gcc version used on these clients changed.
> I dont know if anyone identified what was the cause of these issues

Do you know what clients? You can look at the history to see what the failed test
was and the compiler version used.

I run a gcc trunk client (updated and recompiled with at least two days a week)
that every now and then finds a new bug in gcc that ultimately gets fixed before
trunk is branched into an actual release, so after some days or weeks a test
failing would suddenly disappear.


More information about the ffmpeg-devel mailing list