On 08/03/15 1:25 PM, Reimar Döffinger wrote: > On Sun, Mar 08, 2015 at 01:21:20PM -0300, James Almer wrote: >> On 08/03/15 1:16 PM, Reimar Döffinger wrote: >>> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc >>> in my tests on a G4 7450. >>> >>> Signed-off-by: Reimar Döffinger <reimar.doeffin...@gmx.de> >>> --- >>> libavutil/ppc/intreadwrite.h | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/libavutil/ppc/intreadwrite.h b/libavutil/ppc/intreadwrite.h >>> index 7671676..65b346e 100644 >>> --- a/libavutil/ppc/intreadwrite.h >>> +++ b/libavutil/ppc/intreadwrite.h >>> @@ -24,6 +24,16 @@ >>> #include <stdint.h> >>> #include "config.h" >>> >>> +#if HAVE_ALTIVEC >>> +#include "util_altivec.h" >>> +#if HAVE_BIGENDIAN >>> +#define AV_COPY128(d, s) vec_st(vec_ld(0, (const unsigned char *)(s)), 0, >>> (unsigned char *)(d)) >>> +#else >>> +#define AV_COPY128(d, s) vec_vsx_st(vec_vsx_ld(0, (const unsigned char >>> *)(s)), 0, (unsigned char *)(d)) >>> +#endif >>> +#define AV_ZERO128(d) VEC_ST(vec_splat_u8(0), 0, (unsigned char *)(d)) >>> +#endif >> >> Why not use static av_always_inline functions, like it's done on other >> arches (and >> also for other defines in ppc)? > > Well, it would mean a define and the function itself for overall around 4 > lines of code what like this is a single line. > I don't have much of an opinion, I did that at first, but it just seemed > fairly bloated for what it does. > Also, not using a function is consistent with what the implementations > in the non-arch-specific intreadwrite.h do.
Ah, for some reason i thought i saw a semicolon in one of the defines, meaning more than one line. Fair enough then. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel