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

[James Almer]

On 7/9/2016 4:56 PM, Michael Niedermayer wrote:
> On Sat, Jul 09, 2016 at 04:07:14PM -0300, James Almer wrote:
>> On 7/9/2016 3:28 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sat, Jul 9, 2016 at 1:38 PM, James Almer  wrote:
 [14:31:33] 
 https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116
 looks like some projects using ffmpeg are disabling tree vectorization to
 fix crashes
 [14:33:03]  guess we should disable it for good. it's brought
 more problems than potential performance improvements
 [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows
 [14:35:27] <@nevcairiel> because inline asm and registers
 [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher)
 [14:36:05]  yeah, happened to me
 [14:36:22]  -march=haswell on mingw x86_32 = cabac fails to
 compile
 [14:37:38]  also with 5.x

 Not a lot of arguments remain to keep this in place, so i'll revert this
 change soon if nobody objects.
>>>
>>>
>>> OK.
>>>
>>> Ronald
>>
>> Pushed. Should i backport this to the 3.1 and 3.0 branches?
> 
> if they are affected, yes

They are, yes.

> when in doubt yes

I prefer to ask first :P

Backported.

> 
> thx
> 
> [...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Sat, Jul 09, 2016 at 04:07:14PM -0300, James Almer wrote:
> On 7/9/2016 3:28 PM, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Sat, Jul 9, 2016 at 1:38 PM, James Almer  wrote:
> >> [14:31:33] 
> >> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116
> >> looks like some projects using ffmpeg are disabling tree vectorization to
> >> fix crashes
> >> [14:33:03]  guess we should disable it for good. it's brought
> >> more problems than potential performance improvements
> >> [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows
> >> [14:35:27] <@nevcairiel> because inline asm and registers
> >> [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher)
> >> [14:36:05]  yeah, happened to me
> >> [14:36:22]  -march=haswell on mingw x86_32 = cabac fails to
> >> compile
> >> [14:37:38]  also with 5.x
> >>
> >> Not a lot of arguments remain to keep this in place, so i'll revert this
> >> change soon if nobody objects.
> > 
> > 
> > OK.
> > 
> > Ronald
> 
> Pushed. Should i backport this to the 3.1 and 3.0 branches?

if they are affected, yes
when in doubt yes

thx

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

Observe your enemies, for they first find out your faults. -- Antisthenes


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 7/9/2016 3:28 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Jul 9, 2016 at 1:38 PM, James Almer  wrote:
>> [14:31:33] 
>> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116
>> looks like some projects using ffmpeg are disabling tree vectorization to
>> fix crashes
>> [14:33:03]  guess we should disable it for good. it's brought
>> more problems than potential performance improvements
>> [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows
>> [14:35:27] <@nevcairiel> because inline asm and registers
>> [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher)
>> [14:36:05]  yeah, happened to me
>> [14:36:22]  -march=haswell on mingw x86_32 = cabac fails to
>> compile
>> [14:37:38]  also with 5.x
>>
>> Not a lot of arguments remain to keep this in place, so i'll revert this
>> change soon if nobody objects.
> 
> 
> OK.
> 
> Ronald

Pushed. Should i backport this to the 3.1 and 3.0 branches?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Sat, Jul 9, 2016 at 1:38 PM, James Almer  wrote:

> On 5/8/2016 4:00 AM, Reimar Döffinger wrote:
> > On 07.05.2016, at 02:56, Hendrik Leppkes  wrote:
> >
> >> On Sat, May 7, 2016 at 2:02 AM, James Almer  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.
> >>
> >> Fixing would be nice of course, but it should then only be enabled in
> >> versions we know do not have problems, which is none right now.
> >
> > I had to disable this option for some unrelated projects at work, too,
> since even with 5.2.1 (didn't retest with later) it miscompiled multiple
> pieces of code.
> > And that even on x86_64.
> > I really think there still is an EXTREMELY high risk that it still will
> frequently cause miscompiled code.
> > Unless we actually get above 90% code coverage in FATE I just don't
> think that is a reasonable option for us to ever enable in builds for users!
> > Even for developer builds I have some doubts the speedup we might get at
> some point is worth the time wasted debugging.
> > If we have code parts with a significant speed advantage, enabling it
> only for those and adding targeted tests would be an option.
> > It also avoids the cases where this option can cause some (generally
> very minor) slowdown due to vectorizing loops where it's not worth it.
>
> [14:31:33] 
> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116
> looks like some projects using ffmpeg are disabling tree vectorization to
> fix crashes
> [14:33:03]  guess we should disable it for good. it's brought
> more problems than potential performance improvements
> [14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows
> [14:35:27] <@nevcairiel> because inline asm and registers
> [14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher)
> [14:36:05]  yeah, happened to me
> [14:36:22]  -march=haswell on mingw x86_32 = cabac fails to
> compile
> [14:37:38]  also with 5.x
>
> Not a lot of arguments remain to keep this in place, so i'll revert this
> change soon if nobody objects.


OK.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 5/8/2016 4:00 AM, Reimar Döffinger wrote:
> On 07.05.2016, at 02:56, Hendrik Leppkes  wrote:
> 
>> On Sat, May 7, 2016 at 2:02 AM, James Almer  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.
>>
>> Fixing would be nice of course, but it should then only be enabled in
>> versions we know do not have problems, which is none right now.
> 
> I had to disable this option for some unrelated projects at work, too, since 
> even with 5.2.1 (didn't retest with later) it miscompiled multiple pieces of 
> code.
> And that even on x86_64.
> I really think there still is an EXTREMELY high risk that it still will 
> frequently cause miscompiled code.
> Unless we actually get above 90% code coverage in FATE I just don't think 
> that is a reasonable option for us to ever enable in builds for users!
> Even for developer builds I have some doubts the speedup we might get at some 
> point is worth the time wasted debugging.
> If we have code parts with a significant speed advantage, enabling it only 
> for those and adding targeted tests would be an option.
> It also avoids the cases where this option can cause some (generally very 
> minor) slowdown due to vectorizing loops where it's not worth it.

[14:31:33]  
https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d2d116
 looks like some projects using ffmpeg are disabling tree vectorization to fix 
crashes
[14:33:03]  guess we should disable it for good. it's brought more 
problems than potential performance improvements
[14:35:19] <@nevcairiel> with gcc 6.1 it also doesnt build on windows
[14:35:27] <@nevcairiel> because inline asm and registers
[14:35:54] <@nevcairiel> (doesnt build on x86 if you use -msse or higher)
[14:36:05]  yeah, happened to me
[14:36:22]  -march=haswell on mingw x86_32 = cabac fails to compile
[14:37:38]  also with 5.x

Not a lot of arguments remain to keep this in place, so i'll revert this
change soon if nobody objects.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Clément Bœsch]

On Sun, May 08, 2016 at 11:15:22PM -0300, James Almer wrote:
[...]
> >>> 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=compile=x86_64-archlinux-gcc-threads
> http://fate.ffmpeg.org/log.cgi?time=20160424045346=compile=x86_64-archlinux-gcc-threads

Yeah, I got all kind of freaking random bitflip everywhere, like 2 or 3x a
week (and that's only accounting the one i detected). I recently disabled
a disk from the raid and it doesn't seem to happen anymore so I'm guessing
it's a bug in the HD firmware or something. I'll try to swap the disk in
use for the raid to see if the bit rot happens again starting next week or
so.

Anyway, sorry about that.

And yeah, I haven't updated GCC for a while now, but will do when I figure
out the bitrot shitstorm properly.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  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=compile=x86_64-archlinux-gcc-threads
http://fate.ffmpeg.org/log.cgi?time=20160424045346=compile=x86_64-archlinux-gcc-threads
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  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

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

[James Almer]

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  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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: Enable GCC vectorization on >=4.9

[Paul B Mahol]

On 5/8/16, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, May 8, 2016 at 1:55 PM, 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  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.
>
>
> I'm not trying to use it as a reason to remove the feature, rather as a "if
> there's interesting speedups in code that matters to people, let's do it
> the correct way". I have a half-finished blog post on this subject for
> years now, but can't get myself to finish it. The point is: well-written,
> hand-written assembly is always faster, usually by a huge margin.
>
> So, if it matters, yes, we should hand-write it. If it doesn't matter...
> Well, then ... it doesn't matter anyway, right? (I fully realize this is
> not a black/white thing, but again, it's not a reason to remove, rather
> trying to pick up on code that could be optimized better.)

It all started with devs being lazy and not gonna write assembly.
In this specific case it was vf_phase.c filter code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Sun, May 8, 2016 at 1:55 PM, 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  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.


I'm not trying to use it as a reason to remove the feature, rather as a "if
there's interesting speedups in code that matters to people, let's do it
the correct way". I have a half-finished blog post on this subject for
years now, but can't get myself to finish it. The point is: well-written,
hand-written assembly is always faster, usually by a huge margin.

So, if it matters, yes, we should hand-write it. If it doesn't matter...
Well, then ... it doesn't matter anyway, right? (I fully realize this is
not a black/white thing, but again, it's not a reason to remove, rather
trying to pick up on code that could be optimized better.)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 5/8/2016 10:44 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, May 6, 2016 at 8:02 PM, James Almer  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.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Fri, May 6, 2016 at 8:02 PM, James Almer  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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Reimar Döffinger]

On 07.05.2016, at 02:56, Hendrik Leppkes  wrote:

> On Sat, May 7, 2016 at 2:02 AM, James Almer  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.
> 
> Fixing would be nice of course, but it should then only be enabled in
> versions we know do not have problems, which is none right now.

I had to disable this option for some unrelated projects at work, too, since 
even with 5.2.1 (didn't retest with later) it miscompiled multiple pieces of 
code.
And that even on x86_64.
I really think there still is an EXTREMELY high risk that it still will 
frequently cause miscompiled code.
Unless we actually get above 90% code coverage in FATE I just don't think that 
is a reasonable option for us to ever enable in builds for users!
Even for developer builds I have some doubts the speedup we might get at some 
point is worth the time wasted debugging.
If we have code parts with a significant speed advantage, enabling it only for 
those and adding targeted tests would be an option.
It also avoids the cases where this option can cause some (generally very 
minor) slowdown due to vectorizing loops where it's not worth it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Stephen Hutchinson]

On 5/6/2016 6:08 AM, Hendrik Leppkes wrote:

On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:

On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:


On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:

On 1/30/2016 7:15 PM, Timothy Gu wrote:

FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.


Perhaps this should be restricted to x86?


Fair enough.



Pushed.



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.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



It may also be miscompiling the code on i686 (or specifically MinGW-w64 
builds on i686), since I was encountering segfaults at random at 
startup* in builds of mpv linked against affected FFmpeg builds, but not 
in ffmpeg.exe itself.  Disabling tree vectorization in extra-cflags 
resolved it.


It might work seemingly correctly the first couple invocations,
then start crashing on #4 onward.  But then at a different
time, it would always fail, or work a different number of
times before failing. That was on Silvermont* with 2 GBs of RAM;
on my old Pentium III and 512 MBs of RAM, it seemed to always
fail.

*still 32-bit Windows, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 5/6/2016 9:56 PM, Hendrik Leppkes wrote:
> On Sat, May 7, 2016 at 2:02 AM, James Almer  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.
> 
> Fixing would be nice of course, but it should then only be enabled in
> versions we know do not have problems, which is none right now.
> 
> - Hendrik

Again, do you know the configure options or compile flags that triggered these 
compiler errors? None of the many GCC 5.3 FATE clients reproduce them, so it 
must
be a specific combination of compile flags.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

On Sat, May 7, 2016 at 2:02 AM, James Almer  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.

Fixing would be nice of course, but it should then only be enabled in
versions we know do not have problems, which is none right now.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Timothy Gu]

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?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 5/6/2016 7:08 AM, Hendrik Leppkes wrote:
> On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:
>> On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:
>>>
>>> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
 On 1/30/2016 7:15 PM, Timothy Gu wrote:
> FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.

 Perhaps this should be restricted to x86?
>>>
>>> Fair enough.
>>
>>
>> Pushed.
>>
> 
> 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)

What compile flags? How was ffmpeg configured?
I can try to reproduce it and report the bug to gcc.

> 
> 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.
> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Fri, May 06, 2016 at 12:08:14PM +0200, Hendrik Leppkes wrote:
> On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:
> > On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:
> >>
> >> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
> >> > On 1/30/2016 7:15 PM, Timothy Gu wrote:
> >> > > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
> >> >
> >> > Perhaps this should be restricted to x86?
> >>
> >> Fair enough.
> >
> >
> > Pushed.
> >
> 
> 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.

+1

i had a bad feeling since i saw the patch but failed to find a
case that actually broke with a easy installable compiler at that time
when i tested this back then ...

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Hendrik Leppkes]

On Tue, Feb 9, 2016 at 1:28 AM, Timothy Gu  wrote:
> On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:
>>
>> On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
>> > On 1/30/2016 7:15 PM, Timothy Gu wrote:
>> > > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
>> >
>> > Perhaps this should be restricted to x86?
>>
>> Fair enough.
>
>
> Pushed.
>

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.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Timothy Gu]

On Sun, Jan 31, 2016 at 3:38 PM Timothy Gu  wrote:

On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
> On 1/30/2016 7:15 PM, Timothy Gu wrote:
> > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
>
> Perhaps this should be restricted to x86?

Fair enough.


Pushed.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Timothy Gu]

On Sat, Jan 30, 2016 at 07:27:22PM +, Derek Buitenhuis wrote:
> On 1/30/2016 7:15 PM, Timothy Gu wrote:
> > FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.
> 
> Perhaps this should be restricted to x86?

Fair enough.

Timothy
>From b75076b5d735005a5a8b25d47c21c38cbaebb30b Mon Sep 17 00:00:00 2001
From: Timothy Gu 
Date: Sat, 30 Jan 2016 10:52:44 -0800
Subject: [PATCH] =?UTF-8?q?configure:=20Enable=20GCC=20vectorization=20on?=
 =?UTF-8?q?=20=E2=89=A54.9=20on=20x86?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

4.9 was released precisely nine years after the first GCC version with
autovectorizer (4.0) and six years after the first GCC version with
`-ftree-vectorize` default to enabled on `-O3` (4.3). We've given GCC
enough time to fix those bugs.

FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.

Some optimization hotspots benefit greatly from this change, especially
those without handwritten assembly. For instance, the main function in
vf_phase is now 1.6x faster (1.2x overall) on my machine.
---
 configure | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 44ecfc8..ea8156f 100755
--- a/configure
+++ b/configure
@@ -5934,7 +5934,11 @@ elif enabled ccc; then
 add_cflags -msg_disable nonstandcast
 add_cflags -msg_disable unsupieee
 elif enabled gcc; then
-check_optflags -fno-tree-vectorize
+case $gcc_basever in
+4.9*) enabled x86 || check_optflags -fno-tree-vectorize ;;
+4.*) check_optflags -fno-tree-vectorize ;;
+*)enabled x86 || check_optflags -fno-tree-vectorize ;;
+esac
 check_cflags -Werror=format-security
 check_cflags -Werror=implicit-function-declaration
 check_cflags -Werror=missing-prototypes
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Timothy Gu]

4.9 was released precisely nine years after the first GCC version with
autovectorizer (4.0) and six years after the first GCC version with
`-ftree-vectorize` default to enabled on `-O3` (4.3). We've given GCC
enough time to fix those bugs.

FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.

Some optimization hotspots benefit greatly from this change, especially
those without handwritten assembly. For instance, the main function in
vf_phase is now 1.6x faster (1.2x overall).
---
 configure | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index dba8180..074c4e5 100755
--- a/configure
+++ b/configure
@@ -5933,7 +5933,10 @@ elif enabled ccc; then
 add_cflags -msg_disable nonstandcast
 add_cflags -msg_disable unsupieee
 elif enabled gcc; then
-check_optflags -fno-tree-vectorize
+case $gcc_basever in
+4.9*) ;;
+4.*) check_optflags -fno-tree-vectorize ;;
+esac
 check_cflags -Werror=format-security
 check_cflags -Werror=implicit-function-declaration
 check_cflags -Werror=missing-prototypes
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Derek Buitenhuis]

On 1/30/2016 7:15 PM, Timothy Gu wrote:
> FATE passes here on a x86-64 machine with both GCC 4.9.2 and 5.3.1.

Perhaps this should be restricted to x86?

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel