[FFmpeg-devel] [FFmpeg-cvslog] r11100 - in trunk/libavcodec/i386: cavsdsp_mmx.c dsputil_mmx.c dsputil_mmx.h h264dsp_mmx.c mpegvideo_mmx.c vc1dsp_mmx.c

[Loren Merritt]

On Fri, 30 Nov 2007, Uoti Urpala wrote:

> Would (3) or (4) actually fix compilation in this case? I think the
> addressing mode generated by the compiler causes the problems and AFAIK
> the linker wouldn't change that.

But this addressing is not generated by the compiler, hence the problem.

Static library: inline asm contains a textrel. ok.
Shared library: inline asm still contains a textrel. linker barfs because 
that's not PIC.
Shared library with -Bsymbolic: inline asm still contains a textrel. 
linker resolves the textrel when making the shared library, thus there 
are no textrels in the .so, so it's ok.

> Any linker stuff like (3) or (4) cannot give the full available speedup;
> for that the addressing mode needs to be known at compile time. As I
> wrote in another message the visibility should be marked in the headers
> with either a pragma changing default visibility or a per-symbol macro.
> Those produce identical results but differ in code maintenance
> qualities.

Benchmarks (of x264 not ffmpeg, but they should still be relevant):

x86_64 (Core2)
speed  exe size  version
-2.0%   698928   shared
-1.3%   693584   shared -Bsymbolic
-1.3%   673136   shared -fvisibility=hidden
-0.9%   673104   shared -Bsymbolic -fvisibility=hidden
+0      650208   static

x86_32 (Core2)
speed  exe size  version
-3.2%   736807   shared pic
-2.8%   732071   shared pic -Bsymbolic
-2.7%   715687   shared pic -fvisibility=hidden
-2.7%   715687   shared pic -Bsymbolic -fvisibility=hidden
+0      694232   shared non-pic
+0      660008   static

--Loren Merritt