public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md Date: Fri, 05 Dec 2014 10:50:00 -0000 [thread overview] Message-ID: <bug-64003-4-NCXlV5gElU@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-64003-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003 --- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Uroš Bizjak from comment #23) > (In reply to Ilya Enkovich from comment #21) > > > Then we have three problematic patterns and the easiest way to handle it is > > to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. > > I think the easiest way to do it is to have separate bnd and nobnd patterns > > for these instructions. Attached patch helps me to resolve valgrind error. > > Is such approach fine? > > Maybe "enabled" attribute can help here to avoid unnecessary duplication. No, please disregard the above sentence. The aproach with two patterns looks OK AFAICS. >From gcc-bugs-return-469532-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 05 11:03:40 2014 Return-Path: <gcc-bugs-return-469532-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 28591 invoked by alias); 5 Dec 2014 11:03:40 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 28553 invoked by uid 48); 5 Dec 2014 11:03:34 -0000 From: "petschy at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/64191] New: -march=native messes up dead code elimination in loop calling dtor Date: Fri, 05 Dec 2014 11:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: petschy at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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 Message-ID: <bug-64191-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-12/txt/msg00539.txt.bz2 Content-length: 6269 https://gcc.gnu.org/bugzilla/show_bug.cgi?idd191 Bug ID: 64191 Summary: -march=native messes up dead code elimination in loop calling dtor Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: petschy at gmail dot com Without -march=native, the loops in the 3 fns are eliminated as expected, resulting in single retq's. With -march=native, the loop which calls the defined, but empty dtor is compiled into something rather weird. However, the other empty Nop() call is optimized away as expected. g++-5.0.0 -g -O3 -Wall -Wextra -c 20141205-dtor_loop.cpp g++-5.0.0 -g -O3 -Wall -Wextra -o 20141205-dtor_loop 20141205-dtor_loop.o Dump of assembler code for function foo_dtor_loop(Foo*, unsigned int): 0x0000000000400570 <+0>: repz retq Dump of assembler code for function bar_dtor_loop(Bar*, unsigned int): 0x0000000000400580 <+0>: repz retq Dump of assembler code for function bar_nop_loop(Bar*, unsigned int): 0x0000000000400590 <+0>: repz retq So far so good. g++-5.0.0 -g -O3 -march=native -Wall -Wextra -c 20141205-dtor_loop.cpp g++-5.0.0 -g -O3 -march=native -Wall -Wextra -o 20141205-dtor_loop 20141205-dtor_loop.o Dump of assembler code for function foo_dtor_loop(Foo*, unsigned int): 0x0000000000400570 <+0>: retq Dump of assembler code for function bar_dtor_loop(Bar*, unsigned int): 0x0000000000400578 <+0>: test %rdi,%rdi 0x000000000040057b <+3>: je 0x4005b8 <bar_dtor_loop(Bar*, unsigned int)+64> 0x000000000040057d <+5>: mov %esi,%esi 0x000000000040057f <+7>: lea (%rdi,%rsi,4),%rax 0x0000000000400583 <+11>: cmp %rax,%rdi 0x0000000000400586 <+14>: jae 0x4005b8 <bar_dtor_loop(Bar*, unsigned int)+64> 0x0000000000400588 <+16>: mov $0x3,%edx 0x000000000040058d <+21>: lea -0x4(%rax),%rsi 0x0000000000400591 <+25>: sub %rdi,%rdx 0x0000000000400594 <+28>: add %rsi,%rdx 0x0000000000400597 <+31>: mov %rdx,%rcx 0x000000000040059a <+34>: shr $0x2,%rcx 0x000000000040059e <+38>: lea 0x1(%rcx),%r8 0x00000000004005a2 <+42>: dec %rcx 0x00000000004005a5 <+45>: shr %rcx 0x00000000004005a8 <+48>: lea 0x2(%rcx,%rcx,1),%rcx 0x00000000004005ad <+53>: cmp $0x2f,%rdx 0x00000000004005b1 <+57>: jbe 0x4005b8 <bar_dtor_loop(Bar*, unsigned int)+64> 0x00000000004005b3 <+59>: cmp %rcx,%r8 0x00000000004005b6 <+62>: je 0x4005b8 <bar_dtor_loop(Bar*, unsigned int)+64> 0x00000000004005b8 <+64>: retq Dump of assembler code for function bar_nop_loop(Bar*, unsigned int): 0x00000000004005c0 <+0>: retq The bar_dtor_loop() fn is clearly a mess, unfortunately I can't follow the computation. The bar_inc_loop() does a single int increment on each object, to see what loop code is generated if not empty fns are called. It is as expected: the loop is unrolled 16x times, and the residual part is executed in a tight loop: 0x0000000000400648 <+120>: sub $0x4,%rdx 0x000000000040064c <+124>: incl (%rdx) 0x000000000040064e <+126>: cmp %rdx,%rdi 0x0000000000400651 <+129>: jb 0x400648 <bar_inc_loop(Bar*, unsigned int)+120> g++-5.0.0 -v Using built-in specs. COLLECT_GCC=g++-5.0.0 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --disable-multilib --program-suffix=-5.0.0 Thread model: posix gcc version 5.0.0 20141027 (experimental) (GCC) cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 1 model name : AMD FX(tm)-8150 Eight-Core Processor stepping : 2 microcode : 0x6000626 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs : fxsave_leak bogomips : 7624.63 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb Unfortunately, I couldn't test with the latest version since the build fails with ../.././libcc1/findcomp.cc:20:20: fatal error: config.h: No such file or directory a while know, even after deleting everything and doing a git reset --hard HEAD. ----8<----8<----8<---- struct Foo { int i; }; void foo_dtor_loop(Foo* p, unsigned int n) { if (p) { Foo* e = p + n; while (e > p) { --e; e->~Foo(); } } } struct Bar { int i; ~Bar() { } void Nop() { } void Inc() { ++i; } }; void bar_dtor_loop(Bar* p, unsigned int n) { if (p) { Bar* e = p + n; while (e > p) { --e; e->~Bar(); } } } void bar_nop_loop(Bar* p, unsigned int n) { if (p) { Bar* e = p + n; while (e > p) { --e; e->Nop(); } } } void bar_inc_loop(Bar* p, unsigned int n) { if (p) { Bar* e = p + n; while (e > p) { --e; e->Inc(); } } } int main() { }
next prev parent reply other threads:[~2014-12-05 10:50 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-11-20 18:39 [Bug rtl-optimization/64003] New: " dmalcolm at gcc dot gnu.org 2014-11-20 18:41 ` [Bug rtl-optimization/64003] " dmalcolm at gcc dot gnu.org 2014-11-20 18:54 ` dmalcolm at gcc dot gnu.org 2014-11-20 19:23 ` dmalcolm at gcc dot gnu.org 2014-11-20 19:27 ` dmalcolm at gcc dot gnu.org 2014-11-20 19:41 ` dmalcolm at gcc dot gnu.org 2014-11-21 19:04 ` [Bug target/64003] " dmalcolm at gcc dot gnu.org 2014-12-02 2:20 ` dmalcolm at gcc dot gnu.org 2014-12-02 15:40 ` dmalcolm at gcc dot gnu.org 2014-12-02 15:48 ` dmalcolm at gcc dot gnu.org 2014-12-02 15:54 ` dmalcolm at gcc dot gnu.org 2014-12-02 16:08 ` dmalcolm at gcc dot gnu.org 2014-12-02 16:13 ` dmalcolm at gcc dot gnu.org 2014-12-04 9:24 ` amylaar at gcc dot gnu.org 2014-12-04 18:43 ` law at redhat dot com 2014-12-04 18:44 ` law at redhat dot com 2014-12-04 19:19 ` amylaar at gcc dot gnu.org 2014-12-04 19:38 ` enkovich.gnu at gmail dot com 2014-12-04 19:45 ` amylaar at gcc dot gnu.org 2014-12-04 19:51 ` law at redhat dot com 2014-12-04 19:54 ` law at redhat dot com 2014-12-05 10:07 ` enkovich.gnu at gmail dot com 2014-12-05 10:08 ` enkovich.gnu at gmail dot com 2014-12-05 10:38 ` ubizjak at gmail dot com 2014-12-05 10:50 ` ubizjak at gmail dot com [this message] 2014-12-05 14:19 ` rsandifo at gcc dot gnu.org 2014-12-05 15:01 ` enkovich.gnu at gmail dot com 2014-12-05 16:01 ` ienkovich at gcc dot gnu.org 2015-04-16 14:08 ` ienkovich at gcc dot gnu.org 2015-07-24 8:32 ` ubizjak at gmail dot com 2015-07-24 8:36 ` ubizjak at gmail dot com 2015-07-24 16:26 ` uros at gcc dot gnu.org 2015-07-24 16:31 ` ubizjak at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-64003-4-NCXlV5gElU@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).