GCC 4.3 and later do the right thing with the plain C code. Earlier
versions in 32-bit mode generate one extra instruction, needlessly
zeroing what would be the high half of the shifted value. At least
two gcc configurations miscompile the inline asm in some situations.
In 64-bit mode, all gcc versions generate imul r64, r64 followed by
shr. On Intel i7 and later, this imul is faster 32-bit mul. On
older Intel and all AMD, it is slightly slower. On Atom it is much
slower.
Considering where the FASTDIV macro is used, any overall negative
performance impact of this change should be negligible. If anyone
cares, they should file a bug against gcc and get the instruction
selection fixed.
Signed-off-by: Mans Rullgard <mans@mansr.com>
There is no point in having the user disable any fastdiv macros.
Besides the condition implementation was broken and only disabled
the C implementation, but no platform specific assembly versions.
This is a bit hackish. I will try to think of something nicer, but
this will do for now.
Originally committed as revision 22366 to svn://svn.ffmpeg.org/ffmpeg/trunk
Consistently apply this rule: the guard name is obtained from the
filename by stripping the leading "lib", converting '/' and '.' to
'_' and uppercasing the resulting name. Guard names in the root
directory have to be prefixed by "FFMPEG_".
Originally committed as revision 15120 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Zuxy Meng: zuxy meng gmail com
Original thread:
[FFmpeg-devel] [PATCH] Pure, const and malloc attributes to libavutil
Date: 03/18/2008 6:09 AM
Originally committed as revision 12489 to svn://svn.ffmpeg.org/ffmpeg/trunk
Mans Rullgard
Diego Biurrun
Luca Barbato
Stefano Sabatini
Zuxy Meng
Benoit Fouet