__m128i type

__m128i type

I am having an issue with the compilation in the MTL. I am using MSVC++ in home and I have a linux MTL account, so I am implementing my solutions in a portable way. For this problem I think that using SIMD instructions is the right choice, so I am using the __m128i type.

Well, In the Windows related headers the type is defined as a union with fields like "__int8 m128i_i8[16]" and so on. But I am getting a compilation error when compiling in the MTL machine. The problem seems to be a different union definition, but I can find a compatible union definition in the MTL headers, so I don't understand why I am getting that error. I have solved this issue using my own independent type, but I would like to know why I am getting that error. Maybe the compiler is using other definition in a different header file? More people with same problem?

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


What exactly is the error you're getting? Seeing the exact string might help someone here see what the problem is.

As for myself, I'm trying out the __m128i type on Linux (Ubuntu, GCC 4.4), and it seems to work fine.

Are you including emmintrin.h, or something else?


When I use the dot operator with a __m128i object type, I get the next compiler error:

running.cpp(49): error: expression must have class type

The line of code was:

m_addend.m128i_u8 += val;

MSVC++ compiles it without any error nor warning. The problem seems to be thatintel compilerdoesnt find the enumeration member, so I guess that the compiler is using a different union definition?

Hmmm - looks like that's probably because it's not defined as a union on
Linux. This is the definition it seems to be using on my machine:

typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__));

I've been accessing the type using intrinsics, so maybe that might be a more portable option for you.

I should mention, though: please take my comments as sort of educated guesses, as I'm really not too familiar with SSE :)

Yeah, Im pretty sure that this is the problem. But its a bit confusing that there are header files in the MTL envieronment where this type is defined as a union.

Thanks for your comments.

Are you trying to add just that one or all of the uchars in the m128i?

If all of them then:
use _mm_add_epi8() as it will compile down to a single instruction.
Otherwise what you are wanting todo (under windows) is force the value back into memory to then read the single uchar, do the add and then write back to memory.

The other an options is to do:
__m128i value128;
*((char*)&value128) += value8;

Hi Duncan,

In this line of code I am just trying to modify just one character. I also use _mm_add_epi8() in other situations.
You are right, a casting can be a solution, but I was just wondering why the source wasnt compiling. Finally I decided to define my own union (__oword) in this way:

#if defined (_MSC_VER)
#define OWORD_ALIGNMENT __declspec(align(16))
#define OWORD_ALIGNMENT __attribute__ ((aligned (16)))

typedef union OWORD_ALIGNMENT __oword {
__m128i m128i;
__int8 m128i_i8[16];
__int16 m128i_i16[8];
__int32 m128i_i32[4];
__int64 m128i_i64[2];
unsigned __int8 m128i_u8[16];
unsigned __int16 m128i_u16[8];
unsigned __int32 m128i_u32[4];
unsigned __int64 m128i_u64[2];
} __oword;

so, I can use my_oword.m128i for _mm_* functions and my_oword.whatever in order to access bytes/word/etc.

Even when a casting would give me exactly same results, with this approach I can write a bit more readable source code.

I had the same issue on ACAWIN64 which got fixed by the mtl people upgrading the intel compiler from 11.x to 12.x, if you're just using the u8 field of the union the old 11.x definitions should have a 'u' field that should do the trick for you.

Another alternative is to use the_mm_extract_epi16/_mm_insert_epi16 intrinsics

all the applicable SIMD instruction functions are available in *intrin.h files on MTL.
Just look at the the headers and implement accordingly.

Leave a Comment

Please sign in to add a comment. Not a member? Join today