[FFmpeg-devel] [RFC] replace some static with asm_visibility or so

[Uoti Urpala]

On Sun, 2008-01-27 at 19:27 +0100, Michael Niedermayer wrote:
> reimars suggestion should achive the same at several magnitues less work
> and less risk

> 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

I count a total of 8 uses of attribute_used in libavcodec. Of those 1 is
in h264.c and I've already posted patches which remove the need for it.
The remaining 7 are in i386/. Some of those uses seem unnecessary; for
example the variable tg_1_16 is not used in MANGLE but is already used
as an asm argument, so it should neither get optimized out nor be needed
by any "hidden" asm uses. There are just 3 variables which are declared
with attribute_used AND appear in MANGLE: bone, wm1010 and d40000.

Taking the above into account your "several magnitudes" and "converting
hundreds of asms" claims appear totally out of touch with reality. Even
converting ALL uses of MANGLE (not just those requiring attribute_used)
would not require that amount of work.

> 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

So far I've seen no evidence that giving tables as arguments would be
likely to cause miscompilations. I don't see how asm in particular would
be relevant for GOT use. If you want to minimize indirection through GOT
you should declare visibility whether there is asm or not; and if you're
willing to add relocations where GOT use cannot otherwise be avoided
then you shouldn't be compiling with -fPIC.

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

I see no evidence for any of those claims ("months of work", "more
fragile" or "harder to maintain").