Re: VN, len_store and endianness

[Robin Dapp <rdapp@linux.ibm.com>]

> The error is probably in vn_reference_lookup_3 which assumes that
> 'len' applies to the vector elements in element order.  See the part
> of the code where it checks for internal_store_fn_p.  If 'len' is with
> respect to the memory and thus endianess has to be taken into
> account then for the IFN_LEN_STORE
> 
>               else if (fn == IFN_LEN_STORE)
>                 {
>                   pd.rhs_off = 0;
>                   pd.offset = offset2i;
>                   pd.size = (tree_to_uhwi (len)
>                              + -tree_to_shwi (bias)) * BITS_PER_UNIT;
>                   if (ranges_known_overlap_p (offset, maxsize,
>                                               pd.offset, pd.size))
>                     return data->push_partial_def (pd, set, set,
>                                                    offseti, maxsizei);
> 
> likely needs to adjust rhs_off from zero for big endian?

Not sure I follow entirely.  rhs_off only seems to be used for
native_encode_expr which properly encodes already ({-1, 1, -1, 1} in
that order in memory).  A 'len' of 12 is the first three elements (in
the same order or element order as well).

If the constant were encoded in little endian ({1, -1, 1, -1}) 'q' would
kind of address the right elements (using always the second, or
"reversed third" element while shifting the buffer by 4 bytes each time).