From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B0E163839C44; Mon, 16 Aug 2021 13:16:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0E163839C44 From: "rguenther at suse dot de" 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 13:16:01 +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: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned 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 13:16:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101925 --- Comment #8 from rguenther at suse dot de --- On Mon, 16 Aug 2021, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101925 >=20 > --- Comment #7 from Eric Botcazou --- > > Disabling SRA fixes it also, and I think that SRA drops the rev storage= order > > 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= true. > > Why's that so? How should I detect this is subject to re-ordering? >=20 > Because semantically this does not change anything, but I agree that the = flag > should be set in this case too for the sake of the optimizer. Please rem= ove > the test on QImode on line 8844 in c/c-decl.c. OK, so that fixes it with the vectorizer patch. But then I have no idea why it breaks in the first place. With -fdbg-cnt=3D4:4 (the only "single" vect case that breaks) I see [local count: 1073741824]: ip$is_v4_20 =3D ip.is_v4; - rc =3D {}; + MEM [(struct _be_net_addr *)&rc + 1B] =3D {}; if (ip$is_v4_20 !=3D 0) (huh, guess DSE goes bonkers) - _85 =3D MEM [(union *)&ip + 4B]; + vect_ip6_u_addr8_0_21.88_86 =3D MEM [(union *)&i= p=20 + 4B]; ... - MEM [(union *)&rc + 4B] =3D _85; - rc$u$addr_41 =3D{rev} MEM [(union *)&rc + 4B]; + _39 =3D VIEW_CONVERT_EXPR(vect_ip6_u_addr8_0_21.88_86); looks like bogus FRE here. So both not really vectorization but followup opt issues.=20=20 -fdisable-tree-fre5 makes the testcase work. We're copying REF_REVERSE_STORAGE_ORDER in copy_reference_ops_from_ref but vn_reference_eq doesn't compare .reverse, it only has some early complete out on V_C_E with reverse (aka storage order barriers - whatever those exactly are). Also vn_reference_lookup_3 uses contains_storage_order_barrier_p in two places but that again only checks for the V_C_E barrier, not for reverse accesses. So we're running into /* 4) Assignment from an SSA name which definition we may be able to access pieces from or we can combine to a larger entity. */ else if (known_eq (ref->size, maxsize) && is_gimple_reg_type (vr->type) && !contains_storage_order_barrier_p (vr->operands) && gimple_assign_single_p (def_stmt) && TREE_CODE (gimple_assign_rhs1 (def_stmt)) =3D=3D SSA_NAME) { ... reverse =3D reverse_storage_order_for_component_p (lhs); tree def_rhs =3D gimple_assign_rhs1 (def_stmt); if (!reverse && !storage_order_barrier_p (lhs) && known_size_p (maxsize2) && known_eq (maxsize2, size2) && adjust_offsets_for_equal_base_address (base, &offset, base2, &offset2)) { since LHS is MEM [(union *)&rc + 4B] =3D vect_ip6_u_addr8_0_21.88_86; that doesn't trigger anything. But the ref we're looking at (vr) is from rc$u$addr_41 =3D{rev} MEM [(union *)&rc + 4B]; but we don't check that for reverse_storage_order_for_component_p. We do have check contains_storage_order_barrier_p which easily(?) could at least look for other .reverse =3D=3D 1 compontents but reverse_storage_order_for_component_p is a bit more complicated due to how it handles array and component refs based on their aggregate base TYPE_REVERSE_STORAGE_ORDER. I suppose we could set .reverse for those in copy_reference_ops_from_ref as well. That fixes it.=