[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