SSE, XMM and GMP's configure

[bodrato at mail.dm.unipi.it]

Ciao,

Il Sab, 25 Gennaio 2014 7:15 pm, Torbjorn Granlund ha scritto:
> operating system support.  Now, we suppress use of (some) gcc
> sse-related options which trigger bad behaviour (via the acinclude.m4
> GMP_GCC_PENTIUM4_SSE2) and in that context check of the OS handles XMM
> (via GMP_OS_X86_XMM).

Should we suppress all of them when XMM is not supported? We should add
-march=corei7~-mno-sse2 -march=atom~-mno-sse2 -march=bdver4~-mno-sse2
-march=bdver3~-mno-sse2 -march=bdver2~-mno-sse2 -march=bdver1~-mno-sse2
-march=btver2~-mno-sse2 -march=btver1~-mno-sse2 -march=amdfam10~-mno-sse2
?

> Limiting that check to that context does not properly suppress assembly
> code in sse2 subdirs. Suppressing all that code would actually be
> sub-optimal, since some of it might actually stick to MMX regs.

Does this means move the three offending asm in an xmm subdir, then add:
 case "$path $fat_path" in
   *xmm*)   GMP_OS_X86_XMM($cc $cflags $cppflags, , [GMP_STRIP_PATH(xmm)]) ;;
 esac

?

> I discovered this problem when running tests on the long-obsolete
> FreeBSD 4.

Uhm, a comment in acinclude.m4 says:
dnl      - FreeBSD version 4 is the first supporting xmm.
should we also change the condition there, from
    [freebsd[123] | freebsd[123].*])
to
    [freebsd[1234] | freebsd[1234].*])
?

The first sounds like a lot of work, the second and the third step might
be worth doing, even for a long-obsolete OS.

Regards,
m

-- 
http://bodrato.it/papers/