On 31/10/14 17:01, Matt Turner wrote:
On Fri, Oct 31, 2014 at 4:12 AM, Jose Fonseca <jfons...@vmware.com> wrote:
On 31/10/14 10:13, Juha-Pekka Heikkila wrote:

   defined(__SSE2__) && defined(__GNUC__)


Instead of duplicate this expression everywhere lets create a
"HAVE_SSE2_INTRIN" define.  Not only this expression is complex, it will
become even more when we updated it for MSVC.

Isn't testing __SSE2__ sufficient? Does MSVC not do this?

clang/icc/gcc all implement this and all of the _mm_* intrinsics.


No, __SSE2__ is a GCC-only macro. It's not defined or needed by MSVC compilers. And I strongly suspect that Intel compiler probably only defines it for GCC compatibility.


This is because GCC is quite lame IMO: it can't distinguish between "enabling SSE intrinsics" (ie, allow including emmintrin.h and use the Intel _mm_* instrincis) and emitting SSE2 opcodes own its own accord. That is, when you pass -msse2 to GCC, you're also giving carte blache for GCC to emit SSE2 opcodes for any C code! Which makes it _very_ hard to have special code paths for SSE1/2/3/4/etc and no SSE. Since you basically need to compile each path in a different C module, passing different -msse* flags to each.

Whereas on MSVC, you can #include emmintrin any time, any where, and only the code that uses the intrinsics will generate those opcodes. So you can have a awesomeFuncionC(), awesomeFunctionSSE2(), awesomeFunctionAVX() all next to each other, and a switch table to jump into them.


In other words, on MSVC, instead of

  #if defined(__SSE2__) && defined(__GNUC__)

all you need is

  #if 1

or

  #if defined(_M_IX86) ||  defined(_M_X64)

if you want the code not to cause problems when targetting non-x86 architectures.



Of course there's some merit in GCC emiting SSE instructions for plain C code, but let's face it: virtually all the code that can benefit from SIMD is too complex to be auto-vectorized by compilers, and need humans writing code with SSE intrincs. So GCC is effectively tailored to make the rare thing easy, at the expense of making the common thing hard...


I believe recent GCC versions have better support for having specialized SSE code side-by-side. But from what I remember of it, is all pretty non-standard and GCC specific, so still pretty useless for portable code.


Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to