To access data at multiple fixed offsets from a base address, this
code uses a single "m" operand and code of the form "32%0", relying on
the memory operand instantiation having no displacement, giving a final
result of the form "32(%rax)". If the compiler uses a register and
displacement, e.g. "64(%rax)", the end result becomes "3264(%rax)",
which obviously does not work.
Replacing the "m" operands with "r" operands allows safe addition of a
displacement. In theory, multiple memory operands could use a shared
base register with different index registers, "(%rax,%rbx)", potentially
making more efficient use of registers. In the cases at hand, no such
sharing is possible since the addresses involved are entirely unrelated.
After this change, the code somewhat rudely accesses memory without
using a corresponding memory operand, which in some cases can lead to
unwanted "optimisations" of surrounding code. However, the original
code also accesses memory not covered by a memory operand, so this is
not adding any defect not already present. It is also hightly unlikely
that any such optimisations could be performed here since the memory
locations in questions are not accessed elsewhere in the same functions.
This fixes crashes with suncc.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Refactoring mmx2/mmxext YASM code with cpuflags will force renames.
So switching to a consistent naming scheme beforehand is sensible.
The name "mmxext" is more official and widespread and also the name
of the CPU flag, as reported e.g. by the Linux kernel.
register starvation caused gcc4.2 to fail building 32 bit shared libs
on 64 bit OS X
Signed-off-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Many functions have such a prefix, but do not actually use any
instructions or features from that set, thus giving the false
impression that swscale is highly optimized for a particular
system, whereas in reality it is not.
Many functions have such a prefix, but do not actually use any
instructions or features from that set, thus giving the false
impression that swscale is highly optimized for a particular
system, whereas in reality it is not.
This will be cleaned up in the next merge
Authorship / merged commits:
commit f668afd489
Author: Janne Grunau <janne-libav@jannau.net>
Date: Fri Apr 15 09:12:34 2011 +0200
swscale: fix "ISO C90 forbids mixed declarations and code" warning
only hit with --enable-runtime-cpudetect
commit 7f2ae5c7af
Author: Janne Grunau <janne-libav@jannau.net>
Date: Fri Apr 15 02:09:44 2011 +0200
swscale: fix compilation with --enable-runtime-cpudetect
commit b6cad3df82
Author: Janne Grunau <janne-libav@jannau.net>
Date: Fri Apr 15 00:31:04 2011 +0200
swscale: correct include path to fix ppc altivec build
commit 6216fc70b7
Author: Luca Barbato <lu_zero@gentoo.org>
Date: Thu Apr 14 22:03:45 2011 +0200
swscale: simplify rgb2rgb templating
MMX is always built. Drop the ifdefs
commit 33a0421bba
Author: Josh Allmann <joshua.allmann@gmail.com>
Date: Wed Apr 13 20:57:32 2011 +0200
swscale: simplify initialization code
Simplify the fallthrough case when no accelerated functions
can be initialized.
commit 735bf19511
Author: Josh Allmann <joshua.allmann@gmail.com>
Date: Wed Apr 13 20:57:31 2011 +0200
swscale: further cleanup swscale.c
Move x86-specific constants out of swscale.c
commit 86330b4c92
Author: Luca Barbato <lu_zero@gentoo.org>
Date: Wed Apr 13 20:57:30 2011 +0200
swscale: partially move the arch specific code left
PPC and x86 code is split off from swscale_template.c. Lots of code is
still duplicated and should be removed later.
Again uniformize the init system to be more similar to the dsputil one.
Unset h*scale_fast in the x86 init in order to make the output
consistent with the previous status. Thanks to Josh for spotting it.
commit c003832883
Author: Luca Barbato <lu_zero@gentoo.org>
Date: Wed Apr 13 20:57:29 2011 +0200
swscale: move away x86 specific code from rgb2rgb
Keep only the plain C code in the main rgb2rgb.c and move the x86
specific optimizations to x86/rgb2rgb.c
Change the initialization pattern a little so some of it can be
factorized to behave more like dsputils.
Conflicts:
libswscale/rgb2rgb.c
libswscale/swscale_template.c
Keep only the plain C code in the main rgb2rgb.c and move the x86
specific optimizations to x86/rgb2rgb.c
Change the initialization pattern a little so some of it can be
factorized to behave more like dsputils.
being able to compile it and deduplicate the code at the same time.
Originally committed as revision 30978 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
This is of course done with permissions from the authors. The only GPL
component left are MMX optimizations for YUV to RGB conversion.
Originally committed as revision 30965 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
- Place curly brackets in the same line as while/for/if/switch/else/do;
- Place curly brackets at column 0 in the next line starting a function.
Originally committed as revision 29523 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
- Use 4 spaces throughout for indentation;
- Fix inconsistent indentation;
- Indent function calls and declarations aligning arguments on multiple lines
to the column after the opening parentheses;
- Align asm code to the column 4 spaces after the call to __asm__();
- Align cases in switch statements to the same column as "switch".
Originally committed as revision 29522 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Date: Wed Mar 18 23:11:50 2009
New Revision: 28996
Log:
Fix libswscale compilation on non-x86, hopefully without breaking MinGW64 again.
This change was non optimal, correct would have been to revert the offending commits
if no time was available to find a clean fix.
Originally committed as revision 29003 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
It seems that binutils >= 2.18 just treat eax as rax but older versions fail.
Originally committed as revision 28136 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Neither the asm() nor the __asm__() keyword is not part of the C99
standard, but while GCC accepts the former in C89 syntax, it is not
accepted in C99 unless GNU extensions are turned on (with -fasm). The
latter form is accepted in any syntax as an extension (without
requiring further command-line options).
Sun Studio C99 compiler also does not accept asm() while accepting
__asm__(), albeit reporting warnings that it's not valid C99 synta.
Originally committed as revision 27778 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
These functions are never called by themselves, the alias
interleaveBytes is used instead.
Originally committed as revision 27735 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
Diego Biurrun
Hans-Kristian Arntzen
Giorgio Vazzana
Mans Rullgard
Michael Bradshaw
Anton Khirnov
Ronald S. Bultje
Michael Niedermayer
Luca Barbato
Ramiro Polla
Reimar Döffinger
Zuxy Meng
Cédric Schieli
Aurelien Jacobs
Diego Pettenò