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

[Michael Niedermayer]

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

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- 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/80db9833/attachment.sig>