Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#389 Existence of xmmintrin.h does not imply that it is usable

Portability
open
nobody
5
2011-01-03
2011-01-03
No

I am compiling lame 3.98.4 on Solaris x86 with -xarch=386 for an older system on Solaris 9. Although Solaris 9 in general provides xmmintrin.h it is usable only for architectures that support SSE, which is not the case for the 386 arch. It would be better to also check for the usability of xmmintrin.h in addition to existence.

Discussion

  • Hi, Dagobert.

    Indeed, the availability of SSE is not sufficient for the usability of the instructions. But the problem that you are facing is exactly the same as that faced by distributions, since one can compile the program on a host and run it on a very different machine.

    That being said, can you successfully compile lame? Can you use the --noasm command line option? Does it work without generating a SIGILL?

    I am not exactly sure how to address the problem that you're having, apart from, at runtime, detecting and falling back to what is usable on the particular machine. Or, of course, using the --noasm option...

    Suggestions?

    Regards.

     
  • The problem is slightly different from a distribution as compilation already fails. I want to compile on a platform which essentially may support SSE, but the requested architecture of the build does not, so the compiler throws an error.

    configure does not seem to understand --noasm. In my understanding it should be sufficient to not use --enable-nasm, which I have not set. I used the hackery ac_cv_header_xmmintrin_h=no in my invocation of configure to let it think there are no SSE headers available.

    I think it would be best to test after the availability of xmmintrin.h the compilation of a short program using one of the intrinsics like _mm_set_ss and see if it compiles. This would not solve the distribution problem, but would allow at last allow compilation under all conditions of different compilation flags without hackery.

     
  • I found a construct in the configure.ac from xerces-c which makes a compile test for a similar header:
    AC_COMPILE_IFELSE( [AC_LANG_PROGRAM([[#include <xmmintrin.h>]], [[__m128 one;]])],
    [XMMINTRIN_H=yes],
    [XMMINTRIN_H=no]

     
  • I added a patch for a proper detection whether the intrinsics are there and actually usable. It cleanly applies to 3.99.5.