From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BFB8B3858401; Tue, 12 Oct 2021 17:17:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BFB8B3858401 From: "duan.db at linux dot alibaba.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102714] New: A volatile-related problem cased by ipa inline pass Date: Tue, 12 Oct 2021 17:17:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: duan.db at linux dot alibaba.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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: Tue, 12 Oct 2021 17:17:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102714 Bug ID: 102714 Summary: A volatile-related problem cased by ipa inline pass Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: duan.db at linux dot alibaba.com Target Milestone: --- Created attachment 51592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D51592&action=3Dedit test.i Hi, GCC-trunk has a volatile-related problem with -O2 -fno-strict-aliasing.= =20 The complete test case test.i file is attached. Below are the main caller a= nd callee code snippets: caller code snippets: restart: parent =3D ((void *)0); radix_tree_load_root(root, &node, &maxindex); while (radix_tree_is_internal_node(node)) { parent =3D entry_to_node(node); if (node =3D=3D xa_mk_internal(256)) goto restart; if (parent->shift =3D=3D 0) break; } callee code snippets: static unsigned radix_tree_load_root(const struct xarray *root, struct xa_node **nodep, unsigned long *maxindex) { struct xa_node *node =3D ({typeof(root->xa_head) ________p1 =3D ({(*(const volatile typeof(root->xa= _head) *)&(root->xa_head)); }); ((typeof(*root->xa_head) *)(________p1));}); *nodep =3D node; if (__builtin_expect(!!(radix_tree_is_internal_node(node)), 1)) { node =3D entry_to_node(node); *maxindex =3D node_maxindex(node); return node->shift + (0 ? 4 : 6); } *maxindex =3D 0; return 0; } The callee function radix_tree_load_root will assign the volatile attribute= to root->xa_head (struct member of one input parameter), so that xa_head will = not be optimized by subsequent passes, like loop-invariant code motion. However, during the IPA inline pass, GCC will use function redirect_call_stmt_to_callee to rewrite the call function statement and the intput parameter. In this process, the volatile attribute of xa_head will be lost, which will be optimized and makes the goto jump logic crash.=20 Wrong Assembly code: 0000000000000000 <__radix_tree_lookup>: 0: 4c 8b 47 08 mov 0x8(%rdi),%r8 4: 4c 89 c6 mov %r8,%rsi 7: 4c 89 c0 mov %r8,%rax a: 83 e6 03 and $0x3,%esi d: 48 83 e0 fd and $0xfffffffffffffffd,%rax 11: 31 c9 xor %ecx,%ecx 13: 48 83 fe 02 cmp $0x2,%rsi 17: 75 18 jne 31 <__radix_tree_lookup+0x31> 19: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) 20: 48 89 c1 mov %rax,%rcx 23: 49 81 f8 02 04 00 00 cmp $0x402,%r8 2a: 74 e5 je 11 <__radix_tree_lookup+0x11> //The difference between correct assembly and incorrect assembly is the goto jump. The correct assembly here should be (je 0 <__radix_tree_lookup>), which mea= ns each cycle needs to re-fetch xa_head from the memory. 2c: 80 38 00 cmpb $0x0,(%rax) 2f: 75 ef jne 20 <__radix_tree_lookup+0x20> 31: 48 85 d2 test %rdx,%rdx 34: 74 03 je 39 <__radix_tree_lookup+0x39> 36: 48 89 0a mov %rcx,(%rdx) 39: 4c 89 c0 mov %r8,%rax 3c: c3 retq Like I see, when IPA uses the class ipa_param_adjustments to analyze and s= tore the input parameters information of the call statement, it does not consid= er related volatile information, which leads to the loss of information. And early inline pass does not have this problem, which only exists in IPA inline pass. If lower the limit of early inline pass, the problem can be circumvented. But I am not particularly familiar with this part of GCC code. For how to f= ix this bug, I look forward to getting some suggestions. Thanks a lot.=