[FFmpeg-devel] [PATCH v2 2/2] swscale: Fix AltiVec/VSX build with recent GCC

[Daniel Kolesa]

On Sun, Aug 11, 2019, at 21:39, Reimar Döffinger wrote:
> On 11.08.2019, at 21:24, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > On 07.08.2019, at 19:39, Daniel Kolesa <daniel at octaforge.org> wrote:
> > 
> >> The argument to vec_splat_u16 must be a literal. By making the
> >> function always inline and marking the arguments const, gcc can
> >> turn those into literals, and avoid build errors like:
> > 
> > Why marking the arguments const?
> > If it depends on that it sounds like this might be really unreliable and just work or not work with random compiler versions.
> > It would also be nice to know if/what the impact on code size or performance would be of always inline.
> > An alternative, uglier but likely more reliable option would be to pass the vswap/vshift vectors as arguments and have a macro that generates them (admit the multiple-evaluation risks though)
> > e.g.
> > #define yuv2plane1_16_vsx(s, d, w, b, o) yuv2plane1_16_vsx(s, d, w, b, o, vec_splat_u16(b ? 8 : 0))
> 
> I also realise now that the vec_splat_u16 is just an optimization.
> So maybe the first step would to be to check if there is actually a 
> relevant performance advantage or if it wouldn't be simplest to just 
> use the generic initialization code.

Well, note that this has already been done before http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=153fcd6de6ba558a3720c64589a7e4e9e4d62420

So these changes are just in line with older ones.

> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".