[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