[FFmpeg-devel] [PATCH] enable auto vectorization for gcc 7 and higher

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Soft Works
> Sent: Thursday, July 28, 2022 3:11 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] enable auto vectorization for gcc
> 7 and higher
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > James Almer
> > Sent: Thursday, July 28, 2022 3:05 AM
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] enable auto vectorization for
> gcc
> > 7 and higher
> >
> > On 7/27/2022 10:02 PM, Soft Works wrote:
> > >
> > >> -----Original Message-----
> > >> From: ffmpeg-devel<ffmpeg-devel-bounces at ffmpeg.org>  On Behalf
> Of
> > >> Hendrik Leppkes
> > >> Sent: Wednesday, July 27, 2022 10:42 PM
> > >> To: FFmpeg development discussions and patches <ffmpeg-
> > >> devel at ffmpeg.org>
> > >> Subject: Re: [FFmpeg-devel] [PATCH] enable auto vectorization
> for
> > gcc
> > >> 7 and higher
> > >>
> > >> On Wed, Jul 27, 2022 at 7:39 PM James Almer<jamrial at gmail.com>
> > >> wrote:
> > >>> On 7/27/2022 2:34 PM, Swinney, Jonathan wrote:
> > >>>> I recognize that this patch is going to be somewhat
> > >> controversial. I'm submitting it mostly to see what the opinions
> > are
> > >> and evaluate options. I am working on improving performance for
> > >> aarch64. On that architecture, there are fewer hand written
> > assembly
> > >> implementations of hot functions than there are for x86_64 and
> > >> allowing gcc to auto-vectorize yields noticeable improvements.
> > >>>> Gcc vectorization has improved recently and it hasn't been
> > >> evaluated on the mailing list for a few years. This is the
> latest
> > >> discussion I found in my searches:
> > >> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/193977.html
> > >>> Every time this was done, it was inevitably reverted after
> > >> complains and
> > >>> crash reports started piling up because gcc can't really handle
> > all
> > >> the
> > >>> inline code our codebase has, among other things.
> > >>>
> > >> No need to wait for issues, I just tested, and the same issues
> > still
> > >> persist that have existed for years with GCC now. They don't
> seem
> > to
> > >> care to make it compatible with inline asm, which might be fair
> > >> enough, but it means it just can't work here.
> > >>
> > >> In file included from libavcodec/cabac_functions.h:49,
> > >>                   from libavcodec/h264_cabac.c:36:
> > >> libavcodec/h264_cabac.c: In function 'ff_h264_decode_mb_cabac':
> > >> libavcodec/x86/cabac.h:199:5: error: 'asm' operand has
> impossible
> > >> constraints
> > > I wonder why it doesn't fail when I try the same on MINGW32:
> > >
> > > gcc -I. -Isrc/ -D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1 -
> > D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -
> > U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -
> > D__printf__=__gnu_printf__ -D_POSIX_C_SOURCE=200112 -
> > D_XOPEN_SOURCE=600 -DOPJ_STATIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -
> > DBUILDING_avcodec -mthreads -DLIBTWOLAME_STATIC -std=c11 -
> > IV:/ffbuild/mas/local32/include -
> > IV:/ffbuild/mas/msys64/mingw32/include -I/mingw32/include -
> > IF:/ffbuild/mas/local32/include -DLIBARCHIVE_STATIC -Wdeclaration-
> > after-statement -Wall -Wdisabled-optimization -Wpointer-arith -
> > Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-
> > prototypes -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-
> > switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-
> > variable -Wno-bool-operation -Wno-char-subscripts -O3 -
> Werror=format-
> > security -Werror=implicit-function-declaration -Werror=missing-
> > prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-
> > color=auto -Wno-maybe-uninitialized
> >   -
> > >   ftree-vectorize -MMD -MF libavcodec/h264_cabac.d -MT
> > libavcodec/h264_cabac.o -c -o libavcodec/h264_cabac.o
> > src/libavcodec/h264_cabac.c
> >
> > You didn't set CPU to haswell (Which will add -march=haswell to the
> > command line).
> 
> Yup, you're right - this way I get the same error as Hendrik. Thanks!
> 
> But then, when changing -O3 to -O2, it's compiling without
> error again.

Adding 

#pragma GCC optimize("no-tree-vectorize")

to get_cabac_inline_x86() allows compiling even with -O3
(the attribute approach doesn't seem to work).

softworkz