This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]