[FFmpeg-devel] [PATCH] Export MANGLE definition

Michael Niedermayer michaelni
Sat Dec 15 20:41:12 CET 2007


On Sat, Dec 15, 2007 at 07:06:05PM +0100, Reimar D?ffinger wrote:
> Hello,
> On Sat, Dec 15, 2007 at 07:38:36PM +0200, Uoti Urpala wrote:
> > On Sat, 2007-12-15 at 10:03 +0100, Reimar D?ffinger wrote:
> > > On Fri, Dec 14, 2007 at 10:10:57PM +0200, Uoti Urpala wrote:
> > > > There should be no need to use it. Generally the places which use MANGLE
> > > > should use asm arguments instead.
> > > 
> > > In theory. I tested back then when I tried to compile with ICC, the end
> > > result was that neither ICC nor gcc could compile it because they
> > > thought they needed like 12 registers. I think it was gcc 3.3 back then,
> > > but I am not sure. ICC was version 9. Unless I was actually testing the
> > > Sun compiler not ICC...
> > 
> > Which "it" did they fail to compile? I posted an improved version of
> > cabac.h asm a while ago that did not use MANGLE, and it was tested to
> > work with gcc 4.1 and 4.2 at least. I haven't tried similar cleanup with
> > every piece of asm in FFmpeg of course...
> 
> It was some dsputil stuff. I'm sorry, I didn't write it down.
> If someone makes a patch to change it I'd happily test it on a few
> different compilers (though I admit I don't even have a gcc 3.3 here
> anymore, since it was buggy in other aspects as well).
> Are there any other obvious disadvantages to changing it?

yes
MANGLE gurantees direct, zero overhead and fast access
asm arguments are at the mercy of gccs optimizer and absolutely require
vissibility attributes to be specified

for it to be equally efficient gcc must
0. have vissibility attributes specified for all global variables
1. realize that the code does not need indirection through thr GOT
2. realize that now after 1. it no longer needs the code to init ebx
3. gcc must realize that it doesnt have to and should not load the address
in a register even if one is available

now if gccs asm was known to be solid and bugfree then no doubt asm arguments
would be the way to go but gcc is a buggy pile of ... so things are:

advantage:
 purely stylistic and philosophical, you trade MANGLE against
 attribute visibility
disadvantage:
 extreemly fragile code if it works at all, gcc 3.3 failed as you said yourself

i much prefer to have a hard error and can point at gcc instead of having one
of 500 asms have 4 unneeded GOT indirections before the asm and have ffmpeg
be 50% slower on some obscure OS and have users report that <random commercial
codec> is twice as fast as only hint that there may be something wrong ...

btw, heres some experiment:
    extern const int xxx;
    void func(){
        asm volatile(
            "foobar %0\n\t"
        ::"m"(xxx));
    }
gcc-4.2 (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
gcc-4.2 gotpic.c -S -fomit-frame-pointer -fpic -O3 -o gotpic.s
func:
        call    __i686.get_pc_thunk.cx
        addl    $_GLOBAL_OFFSET_TABLE_, %ecx
        movl    xxx at GOT(%ecx), %eax
#APP
        foobar (%eax)
#NO_APP
        ret
------------------------ with MANGLE:
func:
#APP
        foobar xxx
#NO_APP
        ret

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071215/be53ee25/attachment.pgp>



More information about the ffmpeg-devel mailing list