[FFmpeg-devel] libavcodec/exr : add x86 SIMD for predictor
James Almer
jamrial at gmail.com
Sun Oct 1 18:29:56 EEST 2017
On 10/1/2017 11:35 AM, Henrik Gramner wrote:
> On Sun, Oct 1, 2017 at 4:14 PM, James Almer <jamrial at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
More information about the ffmpeg-devel
mailing list