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

[James Almer]

On 5/8/2016 10:46 PM, Michael Niedermayer wrote:
> On Sun, May 08, 2016 at 10:40:10PM -0300, James Almer wrote:
>> 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 think they where some clients from ubitux IIRC

Ubitux's clients haven't changed the gcc version for some months now. Afaik the
current one is the same as it was before tree vectorization was enabled.
His clients also every now and then fail for some weird reason unrelated to gcc or
even the latest ffmpeg snapshot. They seem to make changes to the source files,
adding random characters that generate errors. See

http://fate.ffmpeg.org/log.cgi?time=20160503100201&log=compile&slot=x86_64-archlinux-gcc-threads
http://fate.ffmpeg.org/log.cgi?time=20160424045346&log=compile&slot=x86_64-archlinux-gcc-threads