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 <jamr...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
