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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Aug 11 22:39:37 EEST 2019


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.



More information about the ffmpeg-devel mailing list