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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160509/51bd2819/attachment.sig>