This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
- From: "scovich at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Jul 2007 14:55:08 -0000
- Subject: [Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
- References: <bug-32662-14600@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from scovich at gmail dot com 2007-07-07 14:55 -------
While it's nice that the new optimization framework can eliminate the redundant
IMUL instruction(s), why were they being generated in the first place?
Compiling the simpler foo() without optimizations gives:
_Z3fooPyPKyy:
.LFB2:
pushq %rbp
.LCFI0:
movq %rsp, %rbp
.LCFI1:
pushq %rbx
.LCFI2:
movq %rdi, -16(%rbp)
movq %rsi, -24(%rbp)
movq %rdx, -32(%rbp)
movq -24(%rbp), %rax
movq (%rax), %rax
movq %rax, %rcx
movl $0, %ebx << here
movq -32(%rbp), %rax
movl $0, %edx << here
movq %rbx, %rsi
imulq %rax, %rsi << here
movq %rdx, %rdi
imulq %rcx, %rdi << here
addq %rdi, %rsi
mulq %rcx
addq %rdx, %rsi
movq %rsi, %rdx
movq %rdx, %rax
xorl %edx, %edx
movq %rax, %rdx
movq -16(%rbp), %rax
movq %rdx, (%rax)
popq %rbx
leave
ret
Barring something really strange it seems like this problem could/should be
fixed at its source, even for 4.1/4.2
Reopen?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662