On Mon, Nov 22, 2010 at 02:33:32PM -0800, David Mathog wrote:
> My software implementation of SSE2 now passes all the testsuite
> programs. In case anybody else ever needs this, it is here:
>
> http://saf.bio.caltech.edu/pub/software/linux_or_unix_tools/soft_emmintrin.h
>
> I compiled that with
The problem is specific for 64 bit environments, made these:
gcc -Wall -msse -mno-sse2 -I. -lm -DSOFT_SSE2 -DEMMSOFTDBG \
-O0 -m32 -S -o gccprob_wno32.s gccprob.c
gcc -Wall -msse -mno-sse2 -I. -lm -DSOFT_SSE2 -DEMMSOFTDBG \
-O0 -m32 -o gccprob_wno32 gccprob.c
gcc -Wall -msse -msse2 -I.
I renamed the test case gccprob.c and made two binaries and two
assembler files:
gcc -Wall -msse -mno-sse2 -I. -lm -DSOFT_SSE2 -DEMMSOFTDBG \
-O0 -o gccprob_wno gccprob.c
gcc -Wall -msse -mno-sse2 -I. -lm -DSOFT_SSE2 -DEMMSOFTDBG \
-O0 -S -o gccprob_wno.s gccprob.c
gcc -Wall -msse -msse
> Things I tried to force a 16 byte stack alignment that didn't work:
>
> 1 -mstackrealign
> 2 -mpreferred-stack-boundary=4
> 3 -mincoming-stack-boundary=4
> 4 2 and 3
> 5 1 and 2 and 3
And this is why they didn't work. Change the test function to
static __m128d __attribute__((noinline,al
I have found several ways to "fix" the latest issue, but they all boil
down to never passing an __m128d value on the call stack. For instance
change
static __m128d
__attribute__((noinline, unused))
test (__m128d s1, __m128d s2)
to
static __m128d test (__m128d s1, __m128d s2)
and the program wo
The last mysterious error message went away when the same code was
compiled on a machine with a more recent gcc (4.4.1). Shortly after
I hit the next roadblock.
Here is foo.c (a modified version of sse2-cmpsd-1.c from the version
4.5.1 testsuite):
>8>8<8>8>8<8>8>8<8>8>8<8>8>8<8>8>8<8>8>8<8>8>8<8
"David Mathog" writes:
> Following your suggestion mo-sse2 was tried, which generated an error
> message well beyond my comprehension:
>
> gcc -std=gnu99 -g -pg -pthread -O4 -DSOFT_SSE2 -msse -mno-sse2
> -DHAVE_CONFIG_H -I../../easel -I../../easel -I. -I.. -I. -I../../src -o
> msvfilter.o -c ms
Ian Lance Taylor wrote:
> No. If I understand what you are doing, I don't think you want to use
> -msse2 at all. In fact I think you want -mno-sse2.
Following your suggestion mo-sse2 was tried, which generated an error
message well beyond my comprehension:
gcc -std=gnu99 -g -pg -pthread -O4 -D
As Ian said, you want to make your emulation inline functions
available when __SSE2__ macro is not defined so that you get the
definitions when -msse2 is not specified, but not getting them when
-msse2 is specified. In the future, gcc may be enhanced to exposed
those mm intrinsics unconditionally (
"David Mathog" writes:
> I compiled that with a target program and gprof showed
> all the time in resulting binary in the inlined functions. It ran about
> 4X slower than the SSE2 hardware version, which is about what I
> expected. So, so far so good. What I am worried about now is that
> sinc
10 matches
Mail list logo
