> I'm probably completely misunderstanding how TYPE_REVERSE_STORAGE_ORDER
> works and what the constraints are. But if the memcpy is the storage order
> barrier then what cases are OK?
>
> - both source and destination objects are [only] accessed with the same
> storage order
> - both source and destination objects are [only] accessed with
> !TYPE_REVERSE_STORAGE_ORDER "containing" accesses
>
> and what determines the "object state" with respect to storage order
> when we see a memcpy call? I had the impression (from the other
> existing cases of contains_storage_order_barrier_p () calls) that
> we derive the "object state" from the downstream access (vr->operands),
> in this case the memcpy destination access. But see below for maybe
> the easier case (memcpy folding).
All cases are OK if you don't try to replace memcpy with something else. The
only possible replacement would be with a VIEW_CONVERT_EXPR, but I guess that
it would be quickly folded into a MEM_EXPR and then we're back to square one.
> In my understanding of how TYPE_REVERSE_STORAGE_ORDER works
> a memcpy, irrespective of its actual "implementation" should not break
> anything since it transfers bytes.
The point of the discussion is precisely to make it work in all cases.
> In particular a 8 byte TYPE_REVERSE_STORAGE_ORDER
> object can be transfered ("memcpy"ed) with (ignoring TBAA)
>
> int tema = *(int *)src;
> *(int *)dst = tema;
> int temb = *((int *)src + 1);
> *((int *)dst + 1) = temb;
>
> and what byteorder the int accesses are performed in is irrelevant
> as long as read and write use the same byteorder.
No, because of the fundamental invariant of the implementation: you may _not_
access the same memory location with different storage orders, this is simply
not supported and we document the limitation in the manual. The program does
not do that, so it's valid; the program after folding does that, which means
that the folding is invalid.
> > Yes, theoritically, but SRA rewrites the access into a scalar access and
> > we're back to square one (I tried).
>
> But what's the issue with this?
Same as above: access to the same location with different storage orders.
> Why? Is the following an invalid program?
>
> void mymemcpy (void *a, void *b) { memcpy (a, b, 8); }
> void foo()
> {
> int b[2] __attribute__(reverse_storage);
> int a[2];
> mymemcpy (a, b);
> return a[0];
> }
>
> how can GCC infer, inside mymemcpy that b is reverse storage order?
No, that's supported, again the point of the discussion is precisely to make
it work!
> Thus, if all this is a problem then I think we're papering over the issue
> by not folding memcpy.
I don't really see why you're insisting on folding memcpy. It's semantically
equivalent to VIEW_CONVERT_EXPR so it needs to be treated the same way.
--
Eric Botcazou
