[FFmpeg-devel] Patch: Inline asm fixes for Intel compiler on Windows

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sat Apr 5 15:47:44 CEST 2014

On Sun, Apr 06, 2014 at 12:21:54AM +1100, Matt Oliver wrote:
> > If you do not initialize "bit", making it an output-only paramenter,
> > you should use =&q instead of +q as constraint.
> > However neither is correct as-is, setae sets only a single byte,
> > thus not initializing it will result in uninitialized data,
> > IOW the code as is is broken.
> > If you want to do that kind of change, you would have to use uint8_t
> > instead as type.
> Interestingly both compilers I tested with didnt show any errors and had
> the upper bits zeroed. However as the function returns a 32b int and any
> code that calls this function would also assume 32b then a xor to set to 0
> initially is still probably the way to go. Using uint8 would save that
> instruction but would add one later to clear the upper bytes should it ever
> be used for anything larger than 1B. So fixed to add back the set to 0.

I think it is better like this since it's an unrelated change.
However when it comes to performance it might be better to use uint8_t,
since this code as-is is very likely to cause partial register stalls
as far as I can tell.
A movzx would increase code size, but not increase number of
instructions and avoid this issue.
It would also free a register if it was moved last and = instead of =&
used (if the compiler manages to figure it out).
Of course only benchmarking would tell if it really is an improvement.

More information about the ffmpeg-devel mailing list