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

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

[Warren D Smith]

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.

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
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

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

[Andrew Pinski]

On Mon, Feb 18, 2019 at 11:15 AM Warren D Smith <warren.wds@gmail.com> 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
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html#Vector-Extensions

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

Thanks,
Andrew


>
> 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
> http://RangeVoting.org  <-- add your endorsement (by clicking
> "endorse" as 1st step)

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

[Warren D Smith]

On 2/18/19, Andrew Pinski <pinskia@gmail.com> wrote:
> GCC already has most of this support.  See
> https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html#Vector-Extensions
>
> The dot in the typenames are not going to supported though.
>
> Thanks,
> Andrew

--what #include files and/or compiler flags are needed to enable this stuff?
(Be nice if that doc page said.)
My gcc allows me to use, e.g.
   c = _mm_shuffle_epi8(a, b);
(and my code worked!) provided I have done
#include <tmmintrin.h>
#include <immintrin.h>

but if I try to replace that with the nicer (since more portable)
   c = __builtin_shuffle(a, b);
then
error: use of unknown builtin '__builtin_shuffle'
[-Wimplicit-function-declaration]

-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)

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

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Wed, 20 Feb 2019, Warren D Smith wrote:
> but if I try to replace that with the nicer (since more portable)
>    c = __builtin_shuffle(a, b);
> then
> error: use of unknown builtin '__builtin_shuffle'
> [-Wimplicit-function-declaration]

Most likely you're on OS X and the 'gcc' command actually invokes Clang/LLVM.
Clang does not implement this builtin (there's __builtin_shufflevector with
a different interface — see Clang documentation for details).

Alexander