Avoiding loss of __restrict__ when using GSL spans

Question

I (mostly) like the new C++ Core Guidelines initiative, and what the Guidelines Support Libary offers. Specifically, I want to use spans more. However, I'm coming up against the issue of __restrict__ not being part of C++ while I want to/need to use it.

To be more concrete: Without span's, I would declare:

void foo(int* __restrict__ p, size_t len);

But if I now declare:

void foo(gsl::span<int> s);

I don't get the __restrict__ effect unless my compiler super-smart. I could pray real hard to the gods of gcc/clang/msvc and say:

void foo(gsl::span<int> __restrict__ s);

or alternatively, I could tweak the GSL span<T> implementation so that the T* begin and T* end pointers are themselves __restrict__'ed. However, it's not at all certain this will be respected.

So, can I force the __restrict__'ion somehow? Or should I just give it up? This kind of takes the fun out of switching to span's...

Swelter

My personal opinion: If you care enough about performance that you want to use __restrict__ on gsl::spanyou probably don't want to use gsl::span in the first place, but first I'd make sure that switching to span actually slows down your program. – Soupandfish

@MikeMB: Why would you say that? It's the exact opposite. We're in C++ ... I want to use a higher level of abstraction and improve performance at the same time... :-) Also, I want to avoid my API blowing up with ever more parameters. – Swelter

@MikeMB: But let me ask you this: How about only using a pointer-and-length pair internally? That is, assigning int* __restrict__ p = s.data(); ? – Swelter

Of course this depends on the particular use case, platform, compiler etc. and my opinion is based on a pretty small data set. However, my general assumption (until I determined otherwise via benchmarks) is that if you care about the 0-10% performance improvement that __restrict__ may provide, the overhead introduced by gsl::span will probably forbidding. If you care about a particular piece of code, where __restrict__ allows the compiler to generate significantly more efficient code then it is very likely, that the added indirection will break those compiler optimizations. – Soupandfish

And when I say "use" I mean actually using the span to access the data (via iterators or the index operator) - not just having a struct that bundles a pointer and a length, which you then split up again – Soupandfish