Idea: extend gcc to save C from the hell of intel vector instructions

Andrew Pinski
Mon Feb 18 19:51:00 GMT 2019

On Mon, Feb 18, 2019 at 11:15 AM Warren D Smith <> wrote:
> There are a lot of weird intel vector instructions like
> #include <emmintrin.h>
> __m128i alignas(16) A, B, C, D, X, Y;
> A = _mm_shuffle_epi8(D, Y);
> C = _mm_unpackhi_epi16(A, B);
> where my gcc seems to know about the latter but not the former
> (I have no idea why, and it is very annoying to arbitrarily support the second
> and not the first).
> Anyhow.  If you write code like that, it is horrible to read.
> But here is a simple idea for improving the C language which would make
> lots of such code easy to read.  And write.
> First of all, there should be (and pretty much are, see   stdint.h, inttypes.h)
> int and uint types of various power of 2 bit sizes, e.g.
> int16 a;
> uint64 b;
> uint128 c;
> uint256 d;
> uint512 e;
> uint4 f;
> where again my gcc supports the first 3 (after appropriate renamings)
> but not the last 3.  (Again, very annoying arbitrariness.)
> But more importantly, we should add new types like this:
> uint128.16 a, b;
> meaning a is 128 bits wide, and consists of 16 chunks, each 8 bits wide,
> each regarded as an 8-bit-wide unsigned int.
> uint256.8 y, z;
> and so on.
> Note the use of DOTS inside the type name.  You could consider other notations,
> I am not fixated on this one.  Another might be  uint128{16}.
> OK, now we could do
> uint128.16 a, b, c;
> c = a+b;   //adds the 16-element vectors a and b elementwise
> c = a-b;  //subtracts vectors
> etc.
> Life is SO much nicer now. It's practically sane again.

GCC already has most of this support.  See

The dot in the typenames are not going to supported though.


> Don't have to keep coming up with all the horrible
> names for each possible kind of vector operation, the compiler does it for you.
> Compiler can check type compatibility and complain if try to
> add incompatible types.  etc etc.
> And for stuff that really should have funny names,
>    b = shuffle(c, d)
> will have meaning pretty obvious from the types of b,c,d,
> and again can complain about type mismatches.
> And the type names will no longer be horrible unreadable strings of
> nonsense characters.
> They will be perfectly readable and logical simple names like uint128.16.
> The present hellish situation is partly intel's fault and partly gcc's fault,
> but it is absurd, that is for sure, and this hell is entirely
> unnecessary, that is
> what really rubs your face in it over and over.
> --
> Warren D. Smith
>  <-- add your endorsement (by clicking
> "endorse" as 1st step)

More information about the Gcc mailing list