[MPlayer-dev-eng] icc benchmark

[Uoti Urpala]

On Mon, 2007-06-11 at 22:54 +0000, Carl Eugen Hoyos wrote:
> Uoti Urpala <uoti.urpala <at> pp1.inet.fi> writes:
> > I think the only non-hacky/ugly way that would also be "guaranteed" to
> > work (as long as the compilers actually work...) would be to use asm
> > constraints. I don't know if there's still compiler brokenness which
> > would prevent this from working with icc 10.0; at least some tests I
> > made seemed to indicate it working correctly.
> > 
> > Attached is an example change for liba52/imdct.c (chosen just because it
> > was the last file among initial icc error messages). The READ_ARRAY
> > macro would obviously be defined in a header instead of per file. This
> > version seems to work right with both gcc and icc.
> 
> I could have bet on it: It doesn't work with gcc-2.95.3

It would be OK to let it break, or you could disable asm optimizations
for those files if you still want to keep some degree of compatibility.

> Except for namespace polution: Is there another disadvantage with global
> variables?

That's a very big "except". Another reason to move from MANGLE to asm
arguments is that almost all current uses of MANGLE are in fact unsafe.
Each asm block must either read and write only the arguments given OR
have "memory" in the globber list. Most of the asm blocks that currently
use MANGLE access the corresponding variable but neither have it in the
arguments nor list "memory" in the globber list. When the variable is a
constant the risk of the compiler coming up with an optimization that
causes the code to break should be low, but it's still wrong; and not
all uses are as safe. Fixing this by adding the "memory" globber would
have a performance penalty since it'd prevent gcc from assuming anything
about the state of any variable after the asm and also prevent keeping
the value of any variable in a register across the asm (since it might
now be out of sync with a changed "real" value in memory).