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?