SSE, XMM and GMP's configure

Torbjorn Granlund tg at
Sun Feb 2 11:37:03 UTC 2014

  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
Perhaps that'd take care of the gcc generated xmm stuff, but again would
suppress sse2+mmx which should be allowed (assuming a cooperating
assembler).  A -mno-xmm is more suitable, but that might already be
implied by a well-configured gcc install.

  > 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)]) ;;
Sort of.  Except that cc, cflags, and cppflags are not defined there, I

  > 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].*])
      [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.
The comment is confusing.  It might be that FreeBSD 4.x (for which x?)
supports xmm but that the FreeBSD code only handles it for the
then-unique xmm chip Pentium 4.  The test system I use is a Haswell,
which with its family code 6 might be assumed to be Pentium pro, II, or
III by the old FreeBSD.

Or the comment is just wrong and FreeBSD 4 doesn't handle xmm at all.

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list