On 10/1/2017 11:35 AM, Henrik Gramner wrote: > On Sun, Oct 1, 2017 at 4:14 PM, James Almer <jamr...@gmail.com> wrote: >> We normally use int for counters, and don't mix declaration and statements. >> And in any case ptrdiff_t would be "more correct" for this. > > Ah right. C90, ugh. Too used to C99.
No, we're c99. c11 even (for atomics only), except for that one thing because we explicitly call gcc with -Wdeclaration-after-statement :P Is it worth warning about it? I don't know. Supposedly some old gcc version in some target would fail with mixed declarations and code even with -std=c99, but by now this is probably just cargo cult. > > Yeah, feel free to use whatever datatype that's most appropriate for > the FFmpeg standard, wouldn't size_t make more sense than ptrdiff_t > for a size though? The counter i is used as a pointer offset, so i think ptrdiff_t is more appropriate. In any case, using int will generate at most a movsxd instruction or similar on 64bit targets. And if we're to start using ptrdiff_t, size_t or whatever instead of int for the counters in for loops then it should be done in general and not just on a single new function. > >> We have both of those in constants.c, so use instead >> >> cextern pb_15 >> cextern pb_80 > > Good point. Any idea why the heck is it called pb_80 btw? Seems like a > very inconsistent mix of decimal and hex. Different developers adding constants as needed, i guess. All pw_ and pd_ constants use decimal, and all pb_ use hex except for 15. And nobody really wants to do cosmetics work :P > >> Does that apply to Haswell and newer? Was wondering why so many of the >> AVX functions that only used the three operand instructions were >> reported to be as fast or even slower than <= SSE4 versions for me. > > Since Ivy Bridge on Intel IIRC. No idea about AMD. Eliminating reg-reg > moves with AVX also saves a little bit of code size (and thus cache) > as well, which might add up over hundreds of functions. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
