[FFmpeg-devel] [RFC] replace some static with asm_visibility or so
Sun Jan 27 19:27:53 CET 2008
On Sun, Jan 27, 2008 at 07:21:40PM +0200, Uoti Urpala wrote:
> On Sun, 2008-01-27 at 16:59 +0100, Michael Niedermayer wrote:
> > seriously, IIRC ICC which this is about cant handle the gazillion asm
> > arguments either, so irronically it could be that there is not a single
> > case, not even obscure which would work any better afterwards
> I tested the cleaned up version of cabac.h asm I posted earlier with ICC
> and it did work (it had 4 array parameters in one asm block). I
> successfully benchmarked decoding with MPlayer that had h264.c compiled
> with ICC, asm enabled (rest of the code was still compiled with gcc). It
> was faster than the gcc version at the time but by less than 10% IIRC.
reimars suggestion should achive the same at several magnitues less work
and less risk
> > and compilation with gcc 2.95, 3.0, 3.1, ... would be totally broken.
> Maybe but those are not too relevant (do you really know whether
> something like 3.0 would work even now?). And asm changes would not
> break anything "totally" in the sense that you could at least compile
> without asm.
> gcc 3.4 would be a somewhat interesting case to test.
> > gcc 4.* and gcc svn might
> > with some luck be able to compile the code as long as you dont try to use
> > PIC on x86-32.
> What current MANGLE does in that case is generate non-PIC code. If you
> don't need it to be fully PIC you could just turn the PIC flag off for
> the affected files.
you can workaround all the problems your suggestion causes, its just adds
on top of converting hundreads of asms and then debugging and maintaining
them so the keep working
the workarounds would be rewriting what gets misscompiled, spliting where
gcc fails to allocate registers, adding attribute vissibility where gcc
decided that it needs to go through the GOT
MANGLE works and compiles the code to the most efficient variant, i dont
doubt that you could change all the code to achive the same without
MANGLE and latest svn gcc after a few month work
but the key point is achive the SAME after MONTHS of work (and end with
more fragile and harder to maintain code)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel