This was missed in d5d699abSigned-off-by: James Almer <jamrial@gmail.com>

The affected functions could also be changed into macros, this is the
smaller change to fix it though. And avoids (probably) less readable macros
The extra code should be optimized out when optimizations are done as all values
are known at build after inlining.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

GCC requires the argument to vec_splat_u32 to be a literal.  The easiest
way to accomplish this is to change 'shift' to be const in scale (as it
is in the transform routine above), and convert both routines to be
inline.  This way, GCC can coerce the values to literals.

Tested on a 970 (Apple G5) and POWER9 (Talos II); passed fate and played
a clip of Big Buck Bunny correctly.

Fixes ticket #7048
Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com>

Silences the following gcc warnings:
src/libavcodec/ppc/h264dsp.c: In function 'ff_h264dsp_init_ppc':
src/libavcodec/ppc/h264dsp.c:809:40: warning: assignment from incompatible pointer type
src/libavcodec/ppc/h264dsp.c:810:40: warning: assignment from incompatible pointer type
src/libavcodec/ppc/h264dsp.c:811:40: warning: assignment from incompatible pointer type
src/libavcodec/ppc/h264dsp.c:812:40: warning: assignment from incompatible pointer type

Silences a gcc warning:
src/libavcodec/ppc/svq1enc_altivec.c: In function 'ff_svq1enc_init_ppc':
src/libavcodec/ppc/svq1enc_altivec.c:80:26: warning: assignment from incompatible pointer type

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Several codecs other than huffyuv use them.
Signed-off-by: James Almer <jamrial@gmail.com>

Also move #includes into canonical order where appropriate.

This is more consistent and fixes compilation with clang.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

This was broken by the following Libav commit:
4c387c70 ppc: dsputil: do unaligned block accesses correctly

The following tests fail due to this:
fate-checkasm
fate-vsynth1-dnxhd-2k-hr-hq fate-vsynth1-dnxhd-edge1-hr
fate-vsynth1-dnxhd-edge2-hr fate-vsynth1-dnxhd-edge3-hr
fate-vsynth1-dnxhd-hr-sq-mov fate-vsynth1-dnxhd-hr-hq-mov
fate-vsynth2-dnxhd-2k-hr-hq fate-vsynth2-dnxhd-edge1-hr
fate-vsynth2-dnxhd-edge2-hr fate-vsynth2-dnxhd-edge3-hr
fate-vsynth2-dnxhd-hr-sq-mov fate-vsynth2-dnxhd-hr-hq-mov
fate-vsynth3-dnxhd-2k-hr-hq fate-vsynth3-dnxhd-edge1-hr
fate-vsynth3-dnxhd-edge2-hr fate-vsynth3-dnxhd-edge3-hr
fate-vsynth3-dnxhd-hr-sq-mov fate-vsynth3-dnxhd-hr-hq-mov

Fixes trac ticket #5508.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Confirmed to work by checkasm.

This avoids SIMD-optimized functions having to sign-extend their
stride argument manually to be able to do pointer arithmetic.

This avoids SIMD-optimized functions having to sign-extend their
stride argument manually to be able to do pointer arithmetic.

ptrdiff_t is the correct type for array strides and similar.

It has no effect, since the code is supposed to operate the same way for
any bit depth.

This avoids SIMD-optimized functions having to sign-extend their
line size argument manually to be able to do pointer arithmetic.

Also adjust parameter names to be "stride" everywhere.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

This avoids SIMD-optimized functions having to sign-extend their
stride argument manually to be able to do pointer arithmetic.

Also adjust parameter names to be "stride" everywhere.

... and attempt to preserve compatibility with clang that was
introduced in 311a953c (untested)
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This commit fixes a broken build when compiling libavcodec with LLVM
compiler. These assembly files use non-standard format that is only
supported by GCC compiler. It would be nice to use a common standard
format. With this patch, both GCC and LLVM can build and generate the
same objects.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This is more consistent with the naming of other decoders.

Restore alphabetical order in lists, break overly long lines, do some
prettyprinting, add some explanatory section comments, group parts
together that belong together logically.

Also fix #endif comments in the FFT init code.

Untested due to lack of ppc.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Whoever wrote this stuff had a pretty bad libm - digits differ pretty
quickly.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This actually fixes an incorrect float literal. It is believed by
examining the precision that the literals were all pre-computed as
floats, resulting in this needless loss of precision. There is no
benefit to keeping such reduced precision:
1. These constants are used for static array computation, hence
compile-time.
2. They will be treated as doubles anyway, since f specifier was not
present.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It is only (mis-)used to set the dsp fucntions clear_block(s). But
these functions always work on 16bits-wide elements, which make
the parameter useless and actually harmful, as it causes all content
on more than 8-bits to not use accelerated functions.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>