On Thu, Jul 9, 2020 at 9:29 AM Eric Botcazou wrote:
>
> > OK with me.
>
> Thanks.
>
> > I still believe we could handle reverse storage order more "optimistically"
> > (without all the current usage restrictions). We seem to have no problems
> > with address-spaces in this area for example (their
> OK with me.
Thanks.
> I still believe we could handle reverse storage order more "optimistically"
> (without all the current usage restrictions). We seem to have no problems
> with address-spaces in this area for example (their problematic cases are
> of course slightly different).
The fundam
On Wed, Jul 8, 2020 at 10:53 AM Eric Botcazou wrote:
>
> [Sorry for dropping the ball here]
>
> > But GCC does not see the reverse storage order in mymemcpy so
> > it happily folds the memcpy inside it, inlines the result and then?
>
> You're right, this breaks, hence the following alternative: ei
[Sorry for dropping the ball here]
> But GCC does not see the reverse storage order in mymemcpy so
> it happily folds the memcpy inside it, inlines the result and then?
You're right, this breaks, hence the following alternative: either we prevent
inlining from happening, or we declare that this
On Tue, Jun 9, 2020 at 12:19 PM Eric Botcazou 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
> 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
On Mon, Jun 8, 2020 at 10:37 AM Eric Botcazou wrote:
>
> > OK, but all I was saying is that looking at the pointed-to type of
> > the address argument to the memcpy looks fragile to me. For the
> > case cited above it would be better to look at the actual
> > reference we are looking up and not a
> OK, but all I was saying is that looking at the pointed-to type of
> the address argument to the memcpy looks fragile to me. For the
> case cited above it would be better to look at the actual
> reference we are looking up and not allowing memcpy handling
> when that reference contains a storage
On Tue, Jun 2, 2020 at 7:11 PM Eric Botcazou wrote:
>
> [Starting with tne VN issue]
>
> > For the VN case the issue is interpreting a read via memcpy (non
> > reverse-storage) as a reverse-storage one when matching up with a hashtable
> > entry from a regular reverse-storage order store, correct?
[Starting with tne VN issue]
> For the VN case the issue is interpreting a read via memcpy (non
> reverse-storage) as a reverse-storage one when matching up with a hashtable
> entry from a regular reverse-storage order store, correct?
It's a read from a scalar (hence native order) combined with a
On Mon, Jun 1, 2020 at 11:09 AM Eric Botcazou wrote:
>
> Hi,
>
> this addresses the issue raised by Andrew a few weeks ago about the usage of
> memory copy functions to toggle the scalar storage order. Recall that you
> cannot (the compiler errors out) take the address of a scalar which is stored
11 matches
Mail list logo
