On Sun, Aug 11, 2019, at 21:39, Reimar Döffinger wrote: > 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.
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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".
