gcc challenges

Dealing with compilers can be quite a challenge sometimes. Recently Mike stumbled over a pretty bad crash on one of his older machines. It looked innocent enough. To enable SSE1/SSE2 intrinsics the only option in gcc is to use '-msse -msse2'. While it did not use SSE to do floating point it does emit cvttss2si instructions to do general floating point conversions if this option is selected. Since his machine was an using an Athlon Model 4 an illegal instruction error killed the browser. SSE1 was introduced with the Athlon XP and Pentium III generations only. This behavior makes it completely impossible to safely do runtime detection of SSE1/SSE2 when using gcc unless you split out the various architectures (x86, MMX, SSE1, SSE2 and SSE3) into separate files and customize compile options which is also the suggested hack in the gcc man pages:

"These options will enable GCC to use these extended instructions in generated code, even without -mfpmath=sse. Applications which perform runtime CPU detection must compile separate files for each supported architecture, using the appropriate flags. In particular, the file containing the CPU detection code should be compiled without these options."

There is also an old bug about this which was essentially rejected. Why is there no option to simply turn on intrinsics? This would make things so much easier for developers and guarantee better portability of source code.

I see two practical options right now: Either we totally disable any SSE1/SSE2 optimizations which will severely cripple performance (yes, some of the rendering code will see a 30-60% slowdown which will affect most users), or, we use the Intel compiler to compile these files. Using ICC would also allow us to compile some of the inline assembly for which I have not created intrinsics yet. The real challenge for me now is to modify the autoconf scripts to use two compilers, something which it does not seem to support by default. Google and various forums I looked on are not of much help either on this subject.

Why not using separate files as suggested by the gcc man pages? Well, it would add another few weeks of refactoring and stabilizing code to make this happen. I fear that I will be tasked with this eventually though.

We also discovered recently that '-O2' can generate bad code and had to switch to '-O1' for the time being. It triggered badness in our support math routines for the JIT and funny enough some rather simple C code (our MMX code works great here):

for ( ; n ; n-- ) {
    uint32 srcP = src[0];
    uint32 src0 = ((srcP&0x0000FF00)<< 8)|
                  ((srcP&0x000000FF)<< 0)|
    uint32 src1 = ((srcP&0xFF000000)>> 8)|
                  ((srcP&0x00FF0000)>>16);

    uint32 dst0 = dst[0];
    uint32 dst1 = dst[1];

    dst0 = ((dst0*(srcP>>24))>>8) + src0;
    dst1 = ((dst1*(srcP>>24))>>8) + src1;

    dst[0] = dst0;
    dst[1] = dst1;

    src+=1;
    dst+=2;
}

This is not reproducible in a standalone test app, I've tried it. Why would gcc make it easy on us anyway? :-) We are trying figure out which option is the issue and disable it. Also, the same code compiles fine using Apple's gcc build 5431 vs gcc 4.0.3 which I am using on Ubuntu right now. Even if it were to fail in a future revision of Apple's version of gcc this code would never be triggered as SSE1 and SSE2 are always guaranteed to be available on MacIntel machines.