[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

Uoti Urpala uoti.urpala
Sat Dec 1 03:53:24 CET 2007


On Fri, 2007-11-30 at 17:56 -0700, Loren Merritt wrote:
> 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.

Yes in this case the generated addressing mode was apparently
PC-relative so the relocation could be removed by the linker (set to the
constant offset to the variable in the same library).

> > 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

Why do the results with both switches differ from just -fvisibility on
AMD64 but not on 32-bit? Are references to symbols matching one that is
defined as hidden resolved at link time (as with -Bsymbolic)?

It would be interesting to see the results with full visibility
information, but I guess you don't have that available. It should give
for each access the advantage that adding -fvisibility gives over just
-Bsymbolic for accesses to symbols defined in the same file, so the
extra benefit would depend on how many uses there are of non-static
symbols defined in the same file vs symbols defined in another file.





More information about the ffmpeg-devel mailing list