0

I wonder if it is possible to tailor strict aliasing requirements to specifically designed cases, while still preserving strict aliasing in general or -O2/-O3 optimization respectively.

To be more precise, in cases where it is needed, strict aliasing can be bypassed using an anonymous union (as pointed out here and here):

#define PTR_CAST(type, x) &(((union {typeof(*x) src; type dst;}*) &(x))->dst)

Now I wonder if using __restrict on a pointer obtained by such a cast would re-enable no-alias optimizations in the compiler (or if such a pointer and all copies of it would be considered potentially aliasing for all times). Like this:

void bar(float* __restrict a, float* __restrict b) {
   // Do something with a and b assuming they don't overlap.
}

void baz(float* c) { /* Do something with c... */ }

void foo() {
   int32_t* buffer = new int32_t[1000];
   // Do something with buffer...

   float* bufCast1 = PTR_CAST(float, buffer);
   float* bufCast2 = PTR_CAST(float, buffer + 500);

   // Can the arguments be successfully __restrict-ed in this case?
   bar(bufCast1, bufCast2);

   // Also, would bufCast1 be treated as potentially aliasing inside of baz()?
   baz(bufCast1);
}
Community
  • 1
  • 1
rsp1984
  • 1,877
  • 21
  • 23
  • Almost everything you mention is not C++, but some compiler extension or other. So consult your compiler's documentation and study the generated machine code. That said, `__restrict` is a promise *by you* that the pointers don't point to overlapping data. – Kerrek SB Sep 06 '13 at 21:58
  • Aliasing through unions is widely supported, to the point where it's technically an extension but portable in the big majority of cases. The `__restrict` is clearly an extension but also one that's widely supported. The question was if `__restrict` *usually* overrides any other aliasing information in the compilation or if it is rendered useless once the compiler's own alias analysis pulls the red flag when encountering a union-based cast. – rsp1984 Sep 06 '13 at 22:07
  • 1
    How would the compiler know? If `bar` is in a separate TU, the compiler has to trust you that you're not lying to it. But as I said, easiest to just check how the machine code comes out. – Kerrek SB Sep 06 '13 at 22:08
  • Well, yea, right, makes sense. I guess clang can do link-time optimizations where it probably would be able to figure this out across TUs. – rsp1984 Sep 06 '13 at 22:17
  • @RafaelSpring: Given that `__restrict` would entitle a compiler to assume that two pointers won't have an aliasing conflict even if they are the same type, why should a compiler not apply the same assumption in other cases where the types would not rule out aliasing but the `__restrict` qualifier would? – supercat Jun 23 '16 at 18:52

0 Answers0