> 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 order barrier? Like
> a && !contains_storage_order_barrier_p (vr->operands) on the whole block
> like we do for the assign from constant/SSA value case?
The memcpy is the storage order barrier though, there is no other, so I'm not
sure what contains_storage_order_barrier_p should be called on. Or do you
mean that an operand should be created for the memcpy with "reverse" set?
> But the above cited case is the _only_ case we're possibly building an
> assignment of a variable - so it's enough to assert that in the above case
> destvar is not TYPE_REVERSE_STORAGE_ORDER?
What about
/* If we can perform the copy efficiently with first doing all loads
and then all stores inline it that way. Currently efficiently
means that we can load all the memory into a single integer
register which is what MOVE_MAX gives us. */
src_align = get_pointer_alignment (src);
It's also a scalar copy, so it won't work either.
> The other cases all build an aggregate copy assignment with
> a non-reverse-storage-order char[size] type which should be OK, no?
Yes, theoritically, but SRA rewrites the access into a scalar access and we're
back to square one (I tried), so this can possibly work only if the array type
is built with TYPE_REVERSE_STORAGE_ORDER too, which implies that the source is
in reverse order too. So the only case that could be handled correctly is the
memcpy between two aggregates types with TYPE_REVERSE_STORAGE_ORDER.
> Note even for the above we probably would be fine if we'd made sure
> to use a !TYPE_REVERSE_STORAGE_ORDER "qualified" type
> for the access. So the memcpy happens via a native order
> load plus a native order store, exactly what memcpy does (in fact
> the actual order does not matter unless the source and destination
> order "agree")? Thus maybe amend
>
> /* Make sure we are not copying using a floating-point mode or
> a type whose size possibly does not match its precision. */
> if (FLOAT_MODE_P (TYPE_MODE (desttype))
>
> || TREE_CODE (desttype) == BOOLEAN_TYPE
> || TREE_CODE (desttype) == ENUMERAL_TYPE)
>
> desttype = bitwise_type_for_mode (TYPE_MODE (desttype));
> if (FLOAT_MODE_P (TYPE_MODE (srctype) )
>
> || TREE_CODE (srctype) == BOOLEAN_TYPE
> || TREE_CODE (srctype) == ENUMERAL_TYPE)
>
> srctype = bitwise_type_for_mode (TYPE_MODE (srctype));
>
> with || TYPE_REVERSE_STORAGE_ORDER (srctype) (same for desttype)?
We don't have TYPE_REVERSE_STORAGE_ORDER qualified types, the flag is only set
on aggregate types and bitwise_type_for_mode will return an integer type.
--
Eric Botcazou
