I'd suggest simply not supporting it to start with, especially when you need to handle multiple compilers. Most games won't benefit significantly from SSE anyway. It also adds significant quantities of extra coding and testing work.

If once you've written the game you find it's running too slow and profiling finds that the game is CPU limited and the hotspots are in functions where SSE would be useful, that is the point to consider using it.

Unfortunately one big downside of SSE is that on the slower CPUs where you want the most extra performance the SSE support is worst (they may not even have it at all).

1)
a) Intel compiler: Yes, and rather sophisticated, however there is a big gotcha. The compiler will insert conditional branches to non-optimized code with abysmal performance for AMD processors (see for example Agner Fog's docs for a reference). For me, this rules out the Intel compiler for any kind of development, regardless of how good it is otherwise.
b) gcc 3.4 : Yes for scalar floating point math, and works very well, too. No support for auto-vectorization.
c) gcc 4.2 : Yes for scalar floating point math, highly optimized. Yes for auto-vectorization if -ftree-vectorize is used, but only works on relatively simple loops.
d) gcc 4.3+: Supposedly better auto-vectorizer, have not tried, however.
e) Microsoft : don't know, don't care

2) At least 4 of them exist, and every compiler should support them
mmintrin.h : MMX
xmmintrin.h : SSE (also includes mmintrin.h)
emmintrin.h : SSE2 (also includes xmmintrin.h)
pmmintrin.h : SSE3 (...)

3) All compilers should support these:
__m128 4 floats
__m128i 4 integers
__m128d 2 doubles

4) no idea

5) Preprocessor macros won't help much, since the preprocessor only knows what platform you compile for, not what platform the code runs on. You will still have to check at runtime or make different binaries.
Or, do what I do, simply restrict yourself to SSE/SSE2 and write "only Pentium IV, Athlon 64, or better" onto the package in big letters. This somehow limits your potential customers, but then again, if someone still uses a Pentium II, he is probably not a customer you want, anyway.

6) This could fill an entire thread alone. In short, they sure do.

7) You can mix and match, although you have to be aware that conversions do impact performance negatively. SSE works best if it can prefetch and load a big bulk of aligned data, perform a dozen vector operations and puke the result back into RAM bypassing caches. Of course it still works in other situations, but not nearly as good.
There are other things to pay attention to, besides using __m128, for example you cannot allocate objects for use with SSE using operator new (not unless you have overloaded it, anyway) if you want to be able to use aligned loads/stores. The unaligned versions are much slower and pretty much ruin the point of using SSE. Also, there are a few quirks with SSE instructions, which differ between manufacturers, too.

8) All reasonably recent AMDs support SSE and SSE2, only the newest dual-cores support SSE3. Funnily, many more AMD processors support SSE than MMX.
SSE and SSE2 should be available on pretty much any Intel chip you encounter, and SSE3 on every reasonably recent one. I don't think any Intel chip supports 3DNow, but honestly I don't know.
Of course, you should never rely on such features, but check cupid instead.

I'd recommend you start by laying out all your data so it is "SSE ready". This enables you to add as much SIMD as you need at any time later, and it enables the compiler to better optimize from the start.
Turning on SSE math can be a big performance boost, especially when using expensive operations. If think you can safely forget about pre-2000 processors (I do), then you should always enable SSE math in your compiler options. It doesn't take any extra work from your side, is perfectly safe, and can make some calculations 2 to 5 times faster (for example square roots).

1) Visual C++ and GCC can't auto-vectorize code, no. Intel's compiler can do it, at least in simple cases. On the whole, it's probably best to do it yourself.

Quote:
It is not clear to me from the explanations of gcc and SIMD, whether the flags for SSE and so on will make the optimizer produce SIMD instructions for standard C++ code, or only allow usage of special datatypes.

What the SSE flags really do is just tell the compiler to generate floating-point code that uses the SSE scalar instructions rather than x87. (SSE consists of SIMD functions as well as plain old-fashioned scalar instructions. These might in some cases be marginally faster than x87 (the "old" FP unit, since 1) they don't have to work with 80bit precision internally, and 2) it works with "normal" registers you can use freely, where x87's registers form a kind of stack (IIRC, one argument to every instruction must be in the "top" register, which obviously leads to some unnecessary register moves)

7)
Try it. [grin]
Obviously, having to shuffle your data around, in and out of SSE registers and to and from SIMD code implies some overhead. What is fastest depends on what your code does.

8)
I think Intel still doesn't support 3dNow, that's true. (Unless AMD made it a requirement for in 64-bit mode, but there wouldn't be much point)
However, AMD supports SSE, SSE2 and SSE3 depending on the age of the CPU. (IIRC, SSE was first supported on Athlon XP, SSE2 on the first Athlon 64's, and SSE3 a year or two later)
In other words, all recent AMD CPU's support all the SSE instructions you're going to need.

Quote:Original post by Spoonbender
1) Visual C++ and GCC can't auto-vectorize code, no.

http://gcc.gnu.org/projects/tree-ssa/vectorization.html