On 11.08.2019, at 21:24, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 07.08.2019, at 19:39, Daniel Kolesa <dan...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
