On Tue, Sep 27, 2022 at 3:19 PM Robin Dapp <rd...@linux.ibm.com> wrote:
>
> > 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).
Yes, because the native_interpret always starts at offset zero
(we can't easily feed in a "shifted" RHS). So what I assumed is
that IFN_LEN_STORE always stores elements [0, len + adj].
> 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).
