public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 @ 2009-04-26 18:24 lucier at math dot purdue dot edu 2009-04-26 18:43 ` [Bug regression/39914] " ubizjak at gmail dot com ` (15 more replies) 0 siblings, 16 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-26 18:24 UTC (permalink / raw) To: gcc-bugs With this compiler: gcc version 4.4.0 20090312 (experimental) [trunk revision 144801] (GCC) running the test in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 (same .i file, same instructions for reproducing, same compiler options, same everything) gives a time of 132 ms cpu time (132 user, 0 system) with assembly code in the main loop of .L2958: movq %rdx, %rcx addq (%r11), %rcx leaq 4(%rdx), %r14 movq %rcx, (%rdi) addq $4, %rcx movq %rcx, (%r10) movq (%r11), %rcx addq (%rdi), %rcx movq %rcx, (%rsi) addq $4, %rcx movq %rcx, (%r9) movq (%r11), %r12 addq (%rsi), %r12 movq %r12, (%rbp) addq $4, %r12 movq %r12, (%r15) movq (%rax), %rcx addq $7, %rcx movsd (%rcx,%r12,2), %xmm7 movq (%rbp), %r12 leaq (%rcx,%rdx,2), %r13 addq $8, %rdx movsd (%r13), %xmm4 movsd (%rcx,%r12,2), %xmm10 movq (%r9), %r12 movsd (%rcx,%r12,2), %xmm5 movq (%rsi), %r12 movsd (%rcx,%r12,2), %xmm6 movq (%r10), %r12 movsd (%rcx,%r12,2), %xmm13 movq (%rdi), %r12 movsd (%rcx,%r12,2), %xmm11 leaq (%r14,%r14), %r12 movsd (%rcx,%r12), %xmm9 movq 24(%r8), %rcx movapd %xmm11, %xmm14 movsd 15(%rcx), %xmm1 movsd 7(%rcx), %xmm2 movapd %xmm1, %xmm8 movsd 31(%rcx), %xmm3 movapd %xmm2, %xmm12 mulsd %xmm10, %xmm8 mulsd %xmm7, %xmm12 mulsd %xmm2, %xmm10 mulsd %xmm1, %xmm7 movsd 23(%rcx), %xmm0 addsd %xmm8, %xmm12 movapd %xmm2, %xmm8 mulsd %xmm6, %xmm2 subsd %xmm7, %xmm10 movapd %xmm1, %xmm7 mulsd %xmm5, %xmm1 mulsd %xmm6, %xmm7 movapd %xmm4, %xmm6 mulsd %xmm5, %xmm8 movapd %xmm9, %xmm5 subsd %xmm10, %xmm14 subsd %xmm1, %xmm2 movapd %xmm3, %xmm1 addsd %xmm11, %xmm10 xorpd .LC5(%rip), %xmm1 addsd %xmm7, %xmm8 movapd %xmm13, %xmm7 subsd %xmm2, %xmm6 subsd %xmm12, %xmm7 subsd %xmm8, %xmm5 addsd %xmm4, %xmm2 movapd %xmm0, %xmm4 addsd %xmm9, %xmm8 movapd %xmm1, %xmm9 mulsd %xmm14, %xmm4 addsd %xmm13, %xmm12 mulsd %xmm7, %xmm9 mulsd %xmm1, %xmm14 movapd %xmm3, %xmm1 mulsd %xmm0, %xmm7 mulsd %xmm10, %xmm1 mulsd %xmm0, %xmm10 addsd %xmm9, %xmm4 subsd %xmm7, %xmm14 movapd %xmm0, %xmm7 movapd %xmm2, %xmm0 mulsd %xmm12, %xmm7 mulsd %xmm3, %xmm12 addsd %xmm1, %xmm7 subsd %xmm12, %xmm10 addsd %xmm10, %xmm0 subsd %xmm10, %xmm2 movsd %xmm0, (%r13) movapd %xmm8, %xmm0 movq (%rax), %rcx subsd %xmm7, %xmm8 addsd %xmm7, %xmm0 movsd %xmm0, 7(%r12,%rcx) movq (%rdi), %r12 movq (%rax), %rcx movapd %xmm6, %xmm0 subsd %xmm14, %xmm6 movsd %xmm2, 7(%rcx,%r12,2) movq (%r10), %r12 movq (%rax), %rcx addsd %xmm14, %xmm0 movsd %xmm8, 7(%rcx,%r12,2) movq (%rsi), %r12 movq (%rax), %rcx movsd %xmm0, 7(%rcx,%r12,2) movapd %xmm5, %xmm0 movq (%r9), %r12 movq (%rax), %rcx subsd %xmm4, %xmm5 addsd %xmm4, %xmm0 movsd %xmm0, 7(%rcx,%r12,2) movq (%rbp), %r12 movq (%rax), %rcx movsd %xmm6, 7(%rcx,%r12,2) movq (%r15), %r12 movq (%rax), %rcx movsd %xmm5, 7(%rcx,%r12,2) cmpq %rdx, -104(%rsp) jg .L2958 movq %r14, -104(%rsp) With this compiler /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.4.0 20090313 (experimental) [trunk revision 144829] (GCC) one gets a time of 212 ms cpu time (212 user, 0 system) and the assembly language for the main loop is .L2946: movq %rbx, %rdx addq (%r11), %rdx leaq 4(%rbx), %rbp movq %rdx, (%rsi) addq $4, %rdx movq %rdx, (%r10) movq (%r11), %rdx addq (%rsi), %rdx movq %rdx, (%rcx) addq $4, %rdx movq %rdx, (%r9) movq (%r11), %r13 addq (%rcx), %r13 movq %r13, (%r8) addq $4, %r13 movq %r13, (%r15) movq (%rax), %rdx addq $7, %rdx movsd (%rdx,%r13,2), %xmm0 leaq (%rdx,%rbx,2), %r14 addq $8, %rbx movsd %xmm0, -48(%rsp) movq (%r8), %r13 movsd (%rdx,%r13,2), %xmm0 movsd %xmm0, -56(%rsp) movq (%r9), %r13 movsd (%rdx,%r13,2), %xmm0 movsd %xmm0, -64(%rsp) movq (%rcx), %r13 movsd (%rdx,%r13,2), %xmm0 movsd %xmm0, -72(%rsp) movq (%r10), %r13 movsd (%rdx,%r13,2), %xmm0 movsd %xmm0, -80(%rsp) movq (%rsi), %r13 movsd (%rdx,%r13,2), %xmm0 leaq (%rbp,%rbp), %r13 movsd %xmm0, -104(%rsp) movsd (%rdx,%r13), %xmm0 movsd %xmm0, -88(%rsp) movq 24(%rdi), %rdx movsd 31(%rdx), %xmm0 movsd %xmm0, -32(%rsp) movsd 23(%rdx), %xmm0 movsd %xmm0, -40(%rsp) movsd 15(%rdx), %xmm0 movsd %xmm0, -112(%rsp) movsd 7(%rdx), %xmm0 movsd %xmm0, -120(%rsp) movapd %xmm0, %xmm1 movsd -112(%rsp), %xmm0 mulsd -48(%rsp), %xmm1 mulsd -56(%rsp), %xmm0 addsd %xmm0, %xmm1 movsd -112(%rsp), %xmm0 mulsd -48(%rsp), %xmm0 movsd %xmm1, -8(%rsp) movsd -120(%rsp), %xmm1 mulsd -56(%rsp), %xmm1 subsd %xmm0, %xmm1 movsd -112(%rsp), %xmm0 mulsd -72(%rsp), %xmm0 movsd %xmm1, -16(%rsp) movsd -120(%rsp), %xmm1 mulsd -64(%rsp), %xmm1 addsd %xmm0, %xmm1 movsd -112(%rsp), %xmm0 mulsd -64(%rsp), %xmm0 movsd %xmm1, -24(%rsp) movsd -120(%rsp), %xmm1 mulsd -72(%rsp), %xmm1 subsd %xmm0, %xmm1 movsd -80(%rsp), %xmm0 subsd -8(%rsp), %xmm0 movsd %xmm1, -120(%rsp) movsd %xmm0, -48(%rsp) movsd -104(%rsp), %xmm0 subsd -16(%rsp), %xmm0 movsd %xmm0, -112(%rsp) movsd -88(%rsp), %xmm0 subsd -24(%rsp), %xmm0 movsd %xmm0, -56(%rsp) movsd (%r14), %xmm0 subsd %xmm1, %xmm0 movsd %xmm0, -64(%rsp) movsd -80(%rsp), %xmm0 addsd -8(%rsp), %xmm0 movsd %xmm0, -80(%rsp) movsd -104(%rsp), %xmm0 addsd -16(%rsp), %xmm0 movsd %xmm0, -104(%rsp) movsd -88(%rsp), %xmm0 addsd -24(%rsp), %xmm0 movsd %xmm0, -88(%rsp) movsd (%r14), %xmm0 addsd %xmm1, %xmm0 movsd %xmm0, -96(%rsp) movsd -32(%rsp), %xmm0 xorpd .LC5(%rip), %xmm0 movsd %xmm0, -120(%rsp) movapd %xmm0, %xmm1 movsd -40(%rsp), %xmm0 mulsd -48(%rsp), %xmm1 mulsd -112(%rsp), %xmm0 addsd %xmm0, %xmm1 movsd -40(%rsp), %xmm0 mulsd -48(%rsp), %xmm0 movsd %xmm1, -72(%rsp) movsd -120(%rsp), %xmm1 mulsd -112(%rsp), %xmm1 subsd %xmm0, %xmm1 movsd -32(%rsp), %xmm0 mulsd -104(%rsp), %xmm0 movsd %xmm1, -112(%rsp) movsd -40(%rsp), %xmm1 mulsd -80(%rsp), %xmm1 addsd %xmm0, %xmm1 movsd -32(%rsp), %xmm0 mulsd -80(%rsp), %xmm0 movsd %xmm1, -120(%rsp) movsd -40(%rsp), %xmm1 mulsd -104(%rsp), %xmm1 subsd %xmm0, %xmm1 movsd %xmm1, -104(%rsp) movsd -96(%rsp), %xmm0 addsd %xmm1, %xmm0 movsd %xmm0, (%r14) movq (%rax), %rdx movsd -88(%rsp), %xmm0 addsd -120(%rsp), %xmm0 movsd %xmm0, 7(%r13,%rdx) movq (%rsi), %r13 movq (%rax), %rdx movsd -96(%rsp), %xmm0 subsd -104(%rsp), %xmm0 movsd %xmm0, 7(%rdx,%r13,2) movq (%r10), %r13 movq (%rax), %rdx movsd -88(%rsp), %xmm0 subsd -120(%rsp), %xmm0 movsd %xmm0, 7(%rdx,%r13,2) movq (%rcx), %r13 movq (%rax), %rdx movsd -64(%rsp), %xmm0 addsd -112(%rsp), %xmm0 movsd %xmm0, 7(%rdx,%r13,2) movq (%r9), %r13 movq (%rax), %rdx movsd -56(%rsp), %xmm0 addsd -72(%rsp), %xmm0 movsd %xmm0, 7(%rdx,%r13,2) movq (%r8), %r13 movq (%rax), %rdx movsd -64(%rsp), %xmm0 subsd -112(%rsp), %xmm0 movsd %xmm0, 7(%rdx,%r13,2) movq (%r15), %r13 movq (%rax), %rdx movsd -56(%rsp), %xmm0 subsd -72(%rsp), %xmm0 movsd %xmm0, 7(%rdx,%r13,2) cmpq %rbx, (%rsp) jg .L2946 movq %rbp, (%rsp) I'm reporting this separately because it doesn't have the same cause as the previous PR 33928 BTW, with 4.2.4 this test runs in 108 ms on this machine, hence the total regression amount noted in the subject line. This part itself causes about 60% performance regression, the rest is accounte for by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 Brad -- Summary: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu @ 2009-04-26 18:43 ` ubizjak at gmail dot com 2009-04-27 8:16 ` ubizjak at gmail dot com ` (14 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: ubizjak at gmail dot com @ 2009-04-26 18:43 UTC (permalink / raw) To: gcc-bugs ------- Comment #1 from ubizjak at gmail dot com 2009-04-26 18:43 ------- There are a couple of possible candidates in this range: URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144812 Log: 2009-03-12 Vladimir Makarov <vmakarov@redhat.com> PR debug/39432 * ira-int.h (struct allocno): Fix comment for calls_crossed_num. * ira-conflicts.c (ira_build_conflicts): Prohibit call used registers for allocnos created from user-defined variables. URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144817 Log: 2009-03-12 H.J. Lu <hongjiu.lu@intel.com> PR target/38824 * config/i386/i386.md: Compare REGNO on the new peephole2 patterns. URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144823 Log: gcc/ 2009-03-12 H.J. Lu <hongjiu.lu@intel.com> PR target/39445 * config/i386/i386.c (ix86_expand_push): Don't set memory alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu 2009-04-26 18:43 ` [Bug regression/39914] " ubizjak at gmail dot com @ 2009-04-27 8:16 ` ubizjak at gmail dot com 2009-04-27 15:07 ` lucier at math dot purdue dot edu ` (13 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: ubizjak at gmail dot com @ 2009-04-27 8:16 UTC (permalink / raw) To: gcc-bugs ------- Comment #2 from ubizjak at gmail dot com 2009-04-27 08:16 ------- (In reply to comment #0) > (same .i file, same instructions for reproducing, same compiler options, same > everything) I guess that this is direct.i compiled with -O1? Trunk, revision: 146825 -O1 on x86_64 linux gives: .L27: leaq 4(%rbx), %rbp movq %rbx, %rdx addq (%r11), %rdx movq %rdx, (%rsi) addq $4, %rdx movq %rdx, (%r10) movq (%r11), %rdx addq (%rsi), %rdx movq %rdx, (%rcx) addq $4, %rdx movq %rdx, (%r9) movq (%r11), %r12 addq (%rcx), %r12 movq %r12, (%r8) addq $4, %r12 movq %r12, (%r15) movq (%rax), %rdx addq $7, %rdx movsd (%rdx,%r12,2), %xmm2 movsd %xmm2, -96(%rsp) movq (%r8), %r12 movsd (%rdx,%r12,2), %xmm2 movsd %xmm2, -64(%rsp) movq (%r9), %r12 movsd (%rdx,%r12,2), %xmm2 movsd %xmm2, -56(%rsp) movq (%rcx), %r12 movsd (%rdx,%r12,2), %xmm2 movsd %xmm2, -48(%rsp) movq (%r10), %r12 movsd (%rdx,%r12,2), %xmm2 movsd %xmm2, -104(%rsp) movq (%rsi), %r12 movsd (%rdx,%r12,2), %xmm2 movsd %xmm2, -88(%rsp) leaq (%rbp,%rbp), %r12 movsd (%r12,%rdx), %xmm2 movsd %xmm2, -80(%rsp) leaq (%rdx,%rbx,2), %r14 movq 24(%rdi), %rdx movsd 31(%rdx), %xmm2 movsd %xmm2, -32(%rsp) movsd 23(%rdx), %xmm2 movsd %xmm2, -40(%rsp) movsd 15(%rdx), %xmm2 movsd %xmm2, -120(%rsp) movsd 7(%rdx), %xmm2 movsd %xmm2, -112(%rsp) movapd %xmm2, %xmm3 mulsd -96(%rsp), %xmm3 movsd -120(%rsp), %xmm2 mulsd -64(%rsp), %xmm2 addsd %xmm2, %xmm3 movsd %xmm3, -24(%rsp) movsd -112(%rsp), %xmm3 mulsd -64(%rsp), %xmm3 movsd -120(%rsp), %xmm2 mulsd -96(%rsp), %xmm2 subsd %xmm2, %xmm3 movsd %xmm3, -96(%rsp) movsd -112(%rsp), %xmm3 mulsd -56(%rsp), %xmm3 movsd -120(%rsp), %xmm2 mulsd -48(%rsp), %xmm2 addsd %xmm2, %xmm3 movsd %xmm3, -64(%rsp) movsd -112(%rsp), %xmm3 mulsd -48(%rsp), %xmm3 movsd -120(%rsp), %xmm2 mulsd -56(%rsp), %xmm2 subsd %xmm2, %xmm3 movsd %xmm3, -120(%rsp) movsd -104(%rsp), %xmm2 subsd -24(%rsp), %xmm2 movsd %xmm2, -112(%rsp) movsd -88(%rsp), %xmm2 subsd -96(%rsp), %xmm2 movsd %xmm2, -56(%rsp) movsd -80(%rsp), %xmm2 subsd -64(%rsp), %xmm2 movsd %xmm2, -48(%rsp) movsd (%r14), %xmm2 subsd %xmm3, %xmm2 movsd %xmm2, -16(%rsp) movsd -104(%rsp), %xmm2 addsd -24(%rsp), %xmm2 movsd %xmm2, -104(%rsp) movsd -88(%rsp), %xmm2 addsd -96(%rsp), %xmm2 movsd %xmm2, -88(%rsp) movsd -80(%rsp), %xmm2 addsd -64(%rsp), %xmm2 movsd %xmm2, -80(%rsp) movsd (%r14), %xmm2 addsd %xmm3, %xmm2 movsd %xmm2, -72(%rsp) movsd -32(%rsp), %xmm2 xorpd %xmm0, %xmm2 movsd %xmm2, -120(%rsp) movapd %xmm2, %xmm3 mulsd -112(%rsp), %xmm3 movsd -40(%rsp), %xmm2 mulsd -56(%rsp), %xmm2 addsd %xmm2, %xmm3 movsd %xmm3, -96(%rsp) movsd -120(%rsp), %xmm3 mulsd -56(%rsp), %xmm3 movsd -40(%rsp), %xmm2 mulsd -112(%rsp), %xmm2 subsd %xmm2, %xmm3 movsd %xmm3, -120(%rsp) movsd -40(%rsp), %xmm3 mulsd -104(%rsp), %xmm3 movsd -32(%rsp), %xmm2 mulsd -88(%rsp), %xmm2 addsd %xmm2, %xmm3 movsd %xmm3, -112(%rsp) movsd -40(%rsp), %xmm3 mulsd -88(%rsp), %xmm3 movsd -32(%rsp), %xmm2 mulsd -104(%rsp), %xmm2 subsd %xmm2, %xmm3 movsd %xmm3, -104(%rsp) movsd -72(%rsp), %xmm2 addsd %xmm3, %xmm2 movsd %xmm2, (%r14) movq (%rax), %rdx movsd -80(%rsp), %xmm2 addsd -112(%rsp), %xmm2 movsd %xmm2, 7(%r12,%rdx) movq (%rsi), %r12 movq (%rax), %rdx movsd -72(%rsp), %xmm2 subsd -104(%rsp), %xmm2 movsd %xmm2, 7(%rdx,%r12,2) movq (%r10), %r12 movq (%rax), %rdx movsd -80(%rsp), %xmm2 subsd -112(%rsp), %xmm2 movsd %xmm2, 7(%rdx,%r12,2) movq (%rcx), %r12 movq (%rax), %rdx movsd -16(%rsp), %xmm2 addsd -120(%rsp), %xmm2 movsd %xmm2, 7(%rdx,%r12,2) movq (%r9), %r12 movq (%rax), %rdx movsd -48(%rsp), %xmm2 addsd -96(%rsp), %xmm2 movsd %xmm2, 7(%rdx,%r12,2) movq (%r8), %r12 movq (%rax), %rdx movsd -16(%rsp), %xmm2 subsd -120(%rsp), %xmm2 movsd %xmm2, 7(%rdx,%r12,2) movq (%r15), %r12 movq (%rax), %rdx movsd -48(%rsp), %xmm2 subsd -96(%rsp), %xmm2 movsd %xmm2, 7(%rdx,%r12,2) addq $8, %rbx cmpq %rbx, -8(%rsp) jg .L27 The code above looks similar to your gcc version 4.4.0 20090313 code. Using -O2, I get: .L27: movq -96(%rsp), %r14 leaq (%rax,%rcx,2), %rdi leaq -8(%rax,%rcx,2), %rbp leaq (%rax,%rsi,2), %r8 leaq -8(%rax,%rsi,2), %r9 leaq 8(%rax,%rdx,2), %r12 movsd (%rdi), %xmm2 leaq 8(%rax,%rbx,2), %r10 movsd (%r14), %xmm4 movq -88(%rsp), %r14 movsd (%rbp), %xmm6 leaq (%rax,%rbx,2), %r11 movsd (%r8), %xmm9 leaq (%rax,%rdx,2), %r13 movsd (%r14), %xmm1 movq -120(%rsp), %r14 movsd (%r9), %xmm10 movq %rcx, -80(%rsp) movapd %xmm1, %xmm14 addq $8, %rdx movsd (%r14), %xmm5 addq $8, %rcx mulsd %xmm6, %xmm14 addq $8, %rsi addq $8, %rbx movapd %xmm5, %xmm7 mulsd %xmm5, %xmm6 movsd (%r12), %xmm11 cmpq %rdx, -112(%rsp) mulsd %xmm2, %xmm7 mulsd %xmm1, %xmm2 movsd (%r15), %xmm8 movsd (%r11), %xmm3 addsd %xmm14, %xmm7 movapd %xmm1, %xmm14 subsd %xmm2, %xmm6 movapd %xmm5, %xmm2 mulsd %xmm10, %xmm14 mulsd %xmm9, %xmm2 mulsd %xmm9, %xmm1 movapd %xmm11, %xmm9 mulsd %xmm10, %xmm5 movsd (%r10), %xmm15 addsd %xmm14, %xmm2 movsd (%r13), %xmm0 movapd %xmm15, %xmm14 subsd %xmm1, %xmm5 movapd %xmm3, %xmm1 subsd %xmm7, %xmm14 movapd %xmm0, %xmm10 subsd %xmm2, %xmm9 addsd %xmm2, %xmm11 movapd %xmm8, %xmm2 subsd %xmm6, %xmm1 xorpd %xmm12, %xmm2 subsd %xmm5, %xmm10 addsd %xmm3, %xmm6 movapd %xmm4, %xmm3 addsd %xmm0, %xmm5 movapd %xmm2, %xmm0 mulsd %xmm1, %xmm3 addsd %xmm15, %xmm7 mulsd %xmm2, %xmm1 mulsd %xmm14, %xmm0 movapd %xmm4, %xmm2 mulsd %xmm4, %xmm14 mulsd %xmm7, %xmm2 addsd %xmm3, %xmm0 movapd %xmm8, %xmm3 mulsd %xmm8, %xmm7 subsd %xmm14, %xmm1 mulsd %xmm6, %xmm3 addsd %xmm3, %xmm2 movapd %xmm4, %xmm3 movapd %xmm5, %xmm4 mulsd %xmm6, %xmm3 subsd %xmm7, %xmm3 addsd %xmm3, %xmm4 subsd %xmm3, %xmm5 movsd %xmm4, (%r13) movapd %xmm11, %xmm4 subsd %xmm2, %xmm11 addsd %xmm2, %xmm4 movapd %xmm10, %xmm2 subsd %xmm1, %xmm10 addsd %xmm1, %xmm2 movsd %xmm4, (%r12) movsd %xmm5, (%r11) movsd %xmm11, (%r10) movsd %xmm2, (%r9) movapd %xmm9, %xmm2 subsd %xmm0, %xmm9 addsd %xmm0, %xmm2 movsd %xmm2, (%r8) movsd %xmm10, (%rbp) movsd %xmm9, (%rdi) jg .L27 It is not clear from your report, if -O1 flag is problematic, -O2 code looks good to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu 2009-04-26 18:43 ` [Bug regression/39914] " ubizjak at gmail dot com 2009-04-27 8:16 ` ubizjak at gmail dot com @ 2009-04-27 15:07 ` lucier at math dot purdue dot edu 2009-04-27 15:11 ` lucier at math dot purdue dot edu ` (12 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-27 15:07 UTC (permalink / raw) To: gcc-bugs ------- Comment #3 from lucier at math dot purdue dot edu 2009-04-27 15:07 ------- Subject: Re: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 On Sun, 2009-04-26 at 18:43 +0000, ubizjak at gmail dot com wrote: > > > ------- Comment #1 from ubizjak at gmail dot com 2009-04-26 18:43 ------- > There are a couple of possible candidates in this range: > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144812 > Log: > 2009-03-12 Vladimir Makarov <vmakarov@redhat.com> > > PR debug/39432 > * ira-int.h (struct allocno): Fix comment for calls_crossed_num. > * ira-conflicts.c (ira_build_conflicts): Prohibit call used > registers for allocnos created from user-defined variables. The problem exists in gcc version 4.4.0 20090312 (experimental) [trunk revision 144812] (GCC) So perhaps it's this checkin. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (2 preceding siblings ...) 2009-04-27 15:07 ` lucier at math dot purdue dot edu @ 2009-04-27 15:11 ` lucier at math dot purdue dot edu 2009-04-27 15:26 ` pinskia at gcc dot gnu dot org ` (11 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-27 15:11 UTC (permalink / raw) To: gcc-bugs ------- Comment #4 from lucier at math dot purdue dot edu 2009-04-27 15:11 ------- Subject: Re: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 On Mon, 2009-04-27 at 08:16 +0000, ubizjak at gmail dot com wrote: > > > ------- Comment #2 from ubizjak at gmail dot com 2009-04-27 08:16 ------- > (In reply to comment #0) > > > (same .i file, same instructions for reproducing, same compiler options, same > > everything) > > I guess that this is direct.i compiled with -O1? > Yes, the compile flags are -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp > It is not clear from your report, if -O1 flag is problematic, -O2 code looks > good to me. Yes, the -O2 code looks good to me, too. I've used the above list of options (starting with -O1) on this code instead of -O2 because the above list (a) has generally given faster performance, and (b) has required much less compile time and memory to compile the C code generated by the Gambit Scheme->C compiler. I have not yet seen any evidence that -O2 generates better code (overall) than those set of options above. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (3 preceding siblings ...) 2009-04-27 15:11 ` lucier at math dot purdue dot edu @ 2009-04-27 15:26 ` pinskia at gcc dot gnu dot org 2009-04-27 15:32 ` lucier at math dot purdue dot edu ` (10 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: pinskia at gcc dot gnu dot org @ 2009-04-27 15:26 UTC (permalink / raw) To: gcc-bugs ------- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-27 15:26 ------- This is by design -O1 is way slower than -O2 now. -- pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (4 preceding siblings ...) 2009-04-27 15:26 ` pinskia at gcc dot gnu dot org @ 2009-04-27 15:32 ` lucier at math dot purdue dot edu 2009-04-27 15:35 ` lucier at math dot purdue dot edu ` (9 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-27 15:32 UTC (permalink / raw) To: gcc-bugs ------- Comment #6 from lucier at math dot purdue dot edu 2009-04-27 15:32 ------- Subject: Re: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 On Mon, 2009-04-27 at 15:26 +0000, pinskia at gcc dot gnu dot org wrote: > This is by design -O1 is way slower than -O2 now. I have seen no general discussion that -O1 should be destroyed as a useful compilation option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (5 preceding siblings ...) 2009-04-27 15:32 ` lucier at math dot purdue dot edu @ 2009-04-27 15:35 ` lucier at math dot purdue dot edu 2009-04-27 16:29 ` lucier at math dot purdue dot edu ` (8 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-27 15:35 UTC (permalink / raw) To: gcc-bugs ------- Comment #7 from lucier at math dot purdue dot edu 2009-04-27 15:35 ------- Subject: Re: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 On Mon, 2009-04-27 at 15:32 +0000, lucier at math dot purdue dot edu wrote: > On Mon, 2009-04-27 at 15:26 +0000, pinskia at gcc dot gnu dot org wrote: > > > This is by design -O1 is way slower than -O2 now. > > I have seen no general discussion that -O1 should be destroyed as a > useful compilation option. Perhaps I should also point out that code generated by -O2 is not generally much faster than before, so if you believe that -O1 is much slower than -O2 now by design, it is only by making code generated by -O1 much slower. BTW, this code runs in 108 ms when compiled with gcc-4.2.4 with the given options (including -O1). Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (6 preceding siblings ...) 2009-04-27 15:35 ` lucier at math dot purdue dot edu @ 2009-04-27 16:29 ` lucier at math dot purdue dot edu 2009-04-27 18:21 ` ubizjak at gmail dot com ` (7 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-27 16:29 UTC (permalink / raw) To: gcc-bugs ------- Comment #8 from lucier at math dot purdue dot edu 2009-04-27 16:29 ------- I hadn't noticed before that Andrew had marked it as "RESOLVED INVALID". I'm reopening it, as I believe that resolving it as INVALID should require a more general discussion than a one-line dismissal of the bug. Brad -- lucier at math dot purdue dot edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (7 preceding siblings ...) 2009-04-27 16:29 ` lucier at math dot purdue dot edu @ 2009-04-27 18:21 ` ubizjak at gmail dot com 2009-04-27 19:04 ` [Bug regression/39914] [4.4/4.5 Regression] " bonzini at gnu dot org ` (6 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: ubizjak at gmail dot com @ 2009-04-27 18:21 UTC (permalink / raw) To: gcc-bugs ------- Comment #9 from ubizjak at gmail dot com 2009-04-27 18:21 ------- Following patch should fix the performance hit with -O1: --cut here-- Index: ira-conflicts.c =================================================================== --- ira-conflicts.c (revision 146825) +++ ira-conflicts.c (working copy) @@ -806,7 +806,7 @@ ira_build_conflicts (void) if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0) /* For debugging purposes don't put user defined variables in callee-clobbered registers. */ - || (optimize <= 1 + || (optimize == 0 && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) != NULL && (decl = attrs->decl) != NULL && VAR_OR_FUNCTION_DECL_P (decl) --cut here-- IMO, such a performance hit is not acceptable with -O1, we want to _optimize_ the code, we have -O0 to achieve full debug functionality. -- ubizjak at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |39432 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2009-04-27 18:21:04 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] [4.4/4.5 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (8 preceding siblings ...) 2009-04-27 18:21 ` ubizjak at gmail dot com @ 2009-04-27 19:04 ` bonzini at gnu dot org 2009-04-27 20:38 ` lucier at math dot purdue dot edu ` (5 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: bonzini at gnu dot org @ 2009-04-27 19:04 UTC (permalink / raw) To: gcc-bugs ------- Comment #10 from bonzini at gnu dot org 2009-04-27 19:04 ------- Yeah, it's basically destroying caller-save optimization. -- bonzini at gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Known to fail| |4.4.0 4.5.0 Known to work| |4.3.3 Summary|96% performance regression |[4.4/4.5 Regression] 96% |in floating point code; part|performance regression in |of the problem started |floating point code; part of |2009/03/12-13 |the problem started | |2009/03/12-13 Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] [4.4/4.5 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (9 preceding siblings ...) 2009-04-27 19:04 ` [Bug regression/39914] [4.4/4.5 Regression] " bonzini at gnu dot org @ 2009-04-27 20:38 ` lucier at math dot purdue dot edu 2009-04-28 1:40 ` lucier at math dot purdue dot edu ` (4 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-27 20:38 UTC (permalink / raw) To: gcc-bugs ------- Comment #11 from lucier at math dot purdue dot edu 2009-04-27 20:37 ------- As far as I can tell, the patch proposed by Uros restores the performance of code generated by gcc version 4.4.0 20090312 (experimental) [trunk revision 144812] (GCC) In particular, the assembly code for the main loop is identical for code generated by gcc version 4.4.0 20090312 (experimental) [trunk revision 144801] (GCC) and by gcc version 4.4.0 20090312 (experimental) [trunk revision 144812] (GCC) after his patch. Thanks for getting to this so quickly. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] [4.4/4.5 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (10 preceding siblings ...) 2009-04-27 20:38 ` lucier at math dot purdue dot edu @ 2009-04-28 1:40 ` lucier at math dot purdue dot edu 2009-04-28 16:18 ` uros at gcc dot gnu dot org ` (3 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: lucier at math dot purdue dot edu @ 2009-04-28 1:40 UTC (permalink / raw) To: gcc-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1459 bytes --] ------- Comment #12 from lucier at math dot purdue dot edu 2009-04-28 01:39 ------- I tried to build and check with this patch, but I got stopped with: /tmp/lucier/gcc/objdirs/mainline/./prev-gcc/xgcc -B/tmp/lucier/gcc/objdirs/mainline/./prev-gcc/ -B/pkgs/gcc-mainline/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../mainline/gcc -I../../../mainline/gcc/build -I../../../mainline/gcc/../include -I../../../mainline/gcc/../libcpp/include -I/tmp/lucier/gcc/objdirs/mainline/./gmp -I/tmp/lucier/gcc/mainline/gmp -I/tmp/lucier/gcc/objdirs/mainline/./mpfr -I/tmp/lucier/gcc/mainline/mpfr -I../../../mainline/gcc/../libdecnumber -I../../../mainline/gcc/../libdecnumber/bid -I../libdecnumber -o build/vec.o ../../../mainline/gcc/vec.c cc1: warnings being treated as errors ../../../mainline/gcc/vec.c: In function vec_descriptor: ../../../mainline/gcc/vec.c:116: error: enum conversion when passing argument 3 of htab_find_slot is invalid in C++ ../../../mainline/gcc/../include/hashtab.h:172: note: expected enum insert_option but argument is of type int make[3]: *** [build/vec.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug regression/39914] [4.4/4.5 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (11 preceding siblings ...) 2009-04-28 1:40 ` lucier at math dot purdue dot edu @ 2009-04-28 16:18 ` uros at gcc dot gnu dot org 2009-04-28 16:19 ` [Bug rtl-optimization/39914] [4.4 " ubizjak at gmail dot com ` (2 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: uros at gcc dot gnu dot org @ 2009-04-28 16:18 UTC (permalink / raw) To: gcc-bugs ------- Comment #13 from uros at gcc dot gnu dot org 2009-04-28 16:18 ------- Subject: Bug 39914 Author: uros Date: Tue Apr 28 16:18:17 2009 New Revision: 146904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146904 Log: PR rtl-optimization/39914 * ira-conflicts.c (ira_build_conflicts): Prohibit call used registers for allocnos created from user-defined variables only when not optimizing. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-conflicts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (12 preceding siblings ...) 2009-04-28 16:18 ` uros at gcc dot gnu dot org @ 2009-04-28 16:19 ` ubizjak at gmail dot com 2009-05-03 19:40 ` uros at gcc dot gnu dot org 2009-05-03 19:41 ` ubizjak at gmail dot com 15 siblings, 0 replies; 17+ messages in thread From: ubizjak at gmail dot com @ 2009-04-28 16:19 UTC (permalink / raw) To: gcc-bugs ------- Comment #14 from ubizjak at gmail dot com 2009-04-28 16:19 ------- Fixed on the trunk so far. -- ubizjak at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Component|regression |rtl-optimization Last reconfirmed|2009-04-27 18:21:04 |2009-04-28 16:19:32 date| | Summary|[4.4/4.5 Regression] 96% |[4.4 Regression] 96% |performance regression in |performance regression in |floating point code; part of|floating point code; part of |the problem started |the problem started |2009/03/12-13 |2009/03/12-13 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (13 preceding siblings ...) 2009-04-28 16:19 ` [Bug rtl-optimization/39914] [4.4 " ubizjak at gmail dot com @ 2009-05-03 19:40 ` uros at gcc dot gnu dot org 2009-05-03 19:41 ` ubizjak at gmail dot com 15 siblings, 0 replies; 17+ messages in thread From: uros at gcc dot gnu dot org @ 2009-05-03 19:40 UTC (permalink / raw) To: gcc-bugs ------- Comment #15 from uros at gcc dot gnu dot org 2009-05-03 19:40 ------- Subject: Bug 39914 Author: uros Date: Sun May 3 19:40:35 2009 New Revision: 147081 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147081 Log: Backport from mainline: 2009-04-28 Uros Bizjak <ubizjak@gmail.com> PR rtl-optimization/39914 * ira-conflicts.c (ira_build_conflicts): Prohibit call used registers for allocnos created from user-defined variables only when not optimizing. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ira-conflicts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug rtl-optimization/39914] [4.4 Regression] 96% performance regression in floating point code; part of the problem started 2009/03/12-13 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu ` (14 preceding siblings ...) 2009-05-03 19:40 ` uros at gcc dot gnu dot org @ 2009-05-03 19:41 ` ubizjak at gmail dot com 15 siblings, 0 replies; 17+ messages in thread From: ubizjak at gmail dot com @ 2009-05-03 19:41 UTC (permalink / raw) To: gcc-bugs ------- Comment #16 from ubizjak at gmail dot com 2009-05-03 19:41 ------- Fixed. -- ubizjak at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2009-05-03 19:41 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-26 18:24 [Bug regression/39914] New: 96% performance regression in floating point code; part of the problem started 2009/03/12-13 lucier at math dot purdue dot edu 2009-04-26 18:43 ` [Bug regression/39914] " ubizjak at gmail dot com 2009-04-27 8:16 ` ubizjak at gmail dot com 2009-04-27 15:07 ` lucier at math dot purdue dot edu 2009-04-27 15:11 ` lucier at math dot purdue dot edu 2009-04-27 15:26 ` pinskia at gcc dot gnu dot org 2009-04-27 15:32 ` lucier at math dot purdue dot edu 2009-04-27 15:35 ` lucier at math dot purdue dot edu 2009-04-27 16:29 ` lucier at math dot purdue dot edu 2009-04-27 18:21 ` ubizjak at gmail dot com 2009-04-27 19:04 ` [Bug regression/39914] [4.4/4.5 Regression] " bonzini at gnu dot org 2009-04-27 20:38 ` lucier at math dot purdue dot edu 2009-04-28 1:40 ` lucier at math dot purdue dot edu 2009-04-28 16:18 ` uros at gcc dot gnu dot org 2009-04-28 16:19 ` [Bug rtl-optimization/39914] [4.4 " ubizjak at gmail dot com 2009-05-03 19:40 ` uros at gcc dot gnu dot org 2009-05-03 19:41 ` ubizjak at gmail dot com
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).