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

[Siarhei Siamashka]

On 30 January 2008, M?ns Rullg?rd wrote:
> > Patches that would fit my description would be for example Ian
> > Caulfield's MLP decoder, some of Christophe Gisquet's optimizations,
> > Siarhei Siamashka's arm idct optimizations (this also shows a double
> > standard, because Mans - who has SVN commit rights - was free to
> > commit suboptimal code, that has never been accepted from anybody
> > without SVN commit rights - I must note however, that IMO it's good
> > that Mans' code was made available early in SVN) or even my sparc
> > idct optimizations - which eventually were comitted, but none of the
> > others I have mentioned have been up to now (for quite some time).
>
> The possible optimisations to the ARM IDCT are minor compared to the
> improvement over the plain C version, and the code in SVN is clean.

I would really appreciate if you benchmarked the code and shared the 
results. My tests show that ARMv5TE optimized IDCT that I tried to submit 
is quite competitive to your ARMv6 implementation and is even faster
(because of the ARM write-allocate cache which is not typical for other
architectures). With a minor patch that changes memory access pattern, 
ARMv6 IDCT regains the leadership. I believe this all has been discussed 
on the mailing list that time.

Anyway, the showstopper was the alignment related code, namely stack
realignment at runtime (in binaries, compiled for legacy OABI systems) 
and the use of ".balign" directive (which is not supported by ancient 
versions of binutils and requires hacks such as ASMALING macro for inline
assembly in C sources).

By the way, a few days ago I had a talk with some guy on #ffmpeg, he tries
to build ffmpeg for iphone. Appears that Apple uses a version/fork of gnu
assembler which is so ancient/broken, that it fails to compile virtually
everything from 'libavcodec/armv4l' directory, even 'jrevdct_arm.S', which has
not been touched for ages (for example, according to his information, '.word'
directives need to be replaced with '.long', etc.). Naturally this version
of assembler does not support '.balign' directive as well :)

Well, some decision need to be done about it. Either we should try to 
tweak code for better support of ancient toolchains (unless it really 
requires too much efforts). Or is it up to Apple to fix their assembler? 
Or investigate the possibility of using normal up to date version of 
binutils when building ffmpeg for Apple devices.

Either way, if the code fails to compile with some weird toolchain, it is
not a big issue (one can always disable assembly optimizations, come here 
and report the problem). Much worse is a breakage at runtime, becasue it is 
a lot harder to debug, especially for inexperienced users (I'm not having
anyone particular in mind).

> I'm not saying it shouldn't be improved, of course.  In fact, I might
> just revisit those patches, which I'd all but forgotten about.  If
> submissions go ignored for a long time, a friendly reminder is often
> useful to get things moving again.  It's easy to forget about things
> you were too busy to look at in detail at the time they were posted.

Thank you, that's completely understandable. I'll try to catch you on
#ffmpeg-devel, so that we could discuss everything. Is it OK?