git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6769 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6768 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6767 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6766 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6765 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6764 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6763 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6762 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6761 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6760 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

use --as-needed just on linux, since *bsd way is broken... (patch from Diego Pettenò <flameeyes@gentoo.org>) 

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6759 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6758 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6757 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

(driver's bug? If not, we will have to support this in some way)


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6756 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6755 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6754 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6753 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6752 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6751 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

8% faster decode_cabac_residual() (8x8 case only) on P3


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6750 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Make configure set CMOV_IS_FAST on arches on which cmov has a low latency
(typically non-Netburst based processor)


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6749 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6748 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6747 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6746 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6745 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6744 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6743 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Sets HAVE_CMOV define so we can protect relevant code with #ifdef HAVE_CMOV


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6742 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

reordering instructions a little in decode_significance_x86() -> 2 instructions less / 1% faster decode_residual on P3


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6741 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6740 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6739 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

in the PIC case nevertheless.
patch by Bernhard Rosenkranzer, bero arklinux org


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6738 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6737 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Almost all CPU targets use -mcpu=xx to set architecture type,
register usage, choice of mnemonics, and instruction
scheduling parameters, except x86, MIPS, HPPA which uses -march=xx


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6736 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6735 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

1 variable less in decode_cabac_residual() no speed change (but less vars means less things gcc can load and store redundantly)


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6734 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6733 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

x86 is 4% faster on P3
C sign stuff + x86 code for everything else is also faster then before (sorry forgot to test pure C)
... and if i replace the second occurance of the sign decoding in decode_residual by the asm too then everything gets slower iam starting to think that it might be best to write the whole function in asm, playing this avoid random deoptimizations game with gcc is not fun at all


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6732 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6731 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@6730 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b