Re: VN, len_store and endianness

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Sep 26, 2022 at 4:21 PM Robin Dapp <rdapp@linux.ibm.com> wrote:
>
> Hi,
>
> I'm locally testing a branch that enables vll/vstl for partial vector
> usage i.e. len_load and len_store on s390.  I see a FAIL in
> testsuite/gfortran.dg/power_3.f90.
> Since r13-1777-gbd9837bc3ca134 we also performe VN for masked/len stores
> and things go wrong there.  The problem seems to be that we evaluate a
> vector constant {-1, 1, -1, 1} loaded with length 11 + 1(bias) = 12 as
> {1, -1, 1} instead of {-1, 1, -1}.
>
> I found it a bit difficult to navigate through the logic due to several
> sizes, offsets, lengths and "amounts" :)  From what I can tell the
> culprit code is (guarded by BYTES_BIG_ENDIAN)
>
>    if (TREE_CODE (pd.rhs) != CONSTRUCTOR)
>      {
>          q = (this_buffer + len
>               - (ROUND_UP (size - amnt, BITS_PER_UNIT)
>                  / BITS_PER_UNIT));
>      }
>
> where, with pd.rhs = { 255, 255, 255, 255, 0, 0, 0, 1, 255, 255, 255,
> 255, 0, 0, 0, 1 }, len = 16 bytes, size = 96 bits, we read after the
> first 32 bits.  What is supposed to happen here?  It looks like going
> backwards (when size grows), but actually size shrinks for my example
> with each successive element via pd.offset 0, -32 and -64.
>
> When skipping the block with && TREE_CODE (pd.rhs) != VECTOR_CST the
> test and various others succeed but I didn't pursue testing further and
> figured I'd rather ask here for more insight.

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?

>
> Regards
>  Robin