On Fri, 2014-10-31 at 17:24 +0000, Jose Fonseca wrote: > 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.
So does anyone have a suggestion how this can be better organised? As in should there be an SSE folder somewhere? Currently streaming-load-memcpy.c is in mesa/main even though its only used by the intel driver, also my patch adds another file there and I've also noticed this [1] which should be made to use a runtime switch too. Dumping everything in Mesa main would obviously get messy fast. [1] http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/intel_tex_subimage.c#n199 > > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
