[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