[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
> 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.

softworkz