[Bug middle-end/107617] New: SCC-VN with len_store and big endian

["rdapp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617

            Bug ID: 107617
           Summary: SCC-VN with len_store and big endian
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rdapp at gcc dot gnu.org
                CC: richard.guenther at gmail dot com
  Target Milestone: ---
            Target: s

Created attachment 53871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53871&action=edit
s390 patch for len_load/len_store

Hi,

Richard and I already quickly discussed this on the mailing list but I didn't
manage to progress analyzing as I was tied up with other things.  Figured I
open a bug for tracking purposes and the possibility to maybe fix it in a later
stage.

I'm evaluating len_load/len_store support on s390 via the attached patch and
seeing a FAIL in

testsuite/gfortran.dg/power_3.f90

built with -march=z16 -O3 --param vect-partial-vector-usage=1

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}.

Richard wrote on the mailing list:
> 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?