On Tue, Jun 9, 2020 at 12:19 PM Eric Botcazou <botca...@adacore.com> wrote:
>
> > 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!
But GCC does not see the reverse storage order in mymemcpy so
it happily folds the memcpy inside it, inlines the result and then?
> > 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.
I'm not insisting on folding memcpy. I'm questioning you are fixing
the actual bug ;)
Richard.
> --
> Eric Botcazou
