From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 499B838515DF; Mon, 16 Aug 2021 10:45:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 499B838515DF From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6 Date: Mon, 16 Aug 2021 10:45:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 10:45:15 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101925 --- Comment #5 from Richard Biener --- So surprisingly the following is not enough to fix it. We still get some vectorizations but those are obviously not with reverse storage accesses. Forcing be_net_addr to be -O0 works around the issue so it's vectorizing of this function. Likewise not inlining be_ip6_addr fixes it as well. Disabling SRA fixes it also, and I think that SRA drops the rev storage ord= er access attribute. Oddly enough for be_ip6_addr I see the rc.u.addr8[] accesses do _not_ result in reverse_storage_order_for_component_p being tru= e. Why's that so? How should I detect this is subject to re-ordering? diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c index d594c0a1b1e..9591d8b9d1a 100644 --- a/gcc/tree-vect-data-refs.c +++ b/gcc/tree-vect-data-refs.c @@ -4291,6 +4291,27 @@ vect_analyze_data_refs (vec_info *vinfo, poly_uint64 *min_vf, bool *fatal) stmt_info->dr_aux.dr =3D dr; stmt_info->dr_aux.stmt =3D stmt_info; + /* We cannot preserve reverse storage order accesses when + vectorizing. */ + if (reverse_storage_order_for_component_p (DR_REF (dr))) + { + if (dump_enabled_p ()) + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, + "not vectorized: ref with reverse storage " + "order in %G", stmt_info->stmt); + if (is_a (vinfo)) + { + /* In BB vectorization the ref can still participate + in dependence analysis, we just can't vectorize it. */ + STMT_VINFO_VECTORIZABLE (stmt_info) =3D false; + continue; + } + return opt_result::failure_at (stmt_info->stmt, + "not vectorized:" + " ref with reverse storage order: = %G", + stmt_info->stmt); + } + /* Check that analysis of the data-ref succeeded. */ if (!DR_BASE_ADDRESS (dr) || !DR_OFFSET (dr) || !DR_INIT=20 I've used for debuggging diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c index d6e63d6e57f..ac5d760efeb 100644 --- a/gcc/gimple-pretty-print.c +++ b/gcc/gimple-pretty-print.c @@ -665,6 +665,9 @@ dump_gimple_assign (pretty_printer *buffer, const gassi= gn *gs, int spc, { dump_generic_node (buffer, gimple_assign_lhs (gs), spc, flags, false); pp_space (buffer); + + if (reverse_storage_order_for_component_p (gimple_assign_lhs (gs)= )) + pp_string (buffer, "{rev}"); pp_equal (buffer); if (gimple_assign_nontemporal_move_p (gs)) @@ -673,6 +676,8 @@ dump_gimple_assign (pretty_printer *buffer, const gassi= gn *gs, int spc, if (gimple_has_volatile_ops (gs)) pp_string (buffer, "{v}"); + if (reverse_storage_order_for_component_p (gimple_assign_rhs1 (gs= ))) + pp_string (buffer, "{rev}"); pp_space (buffer); }=