From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11792 invoked by alias); 28 Nov 2004 21:27:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 11777 invoked from network); 28 Nov 2004 21:27:17 -0000 Received: from unknown (HELO webmail-outgoing.us4.outblaze.com) (205.158.62.67) by sourceware.org with SMTP; 28 Nov 2004 21:27:17 -0000 Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 6C81318001B3 for ; Sun, 28 Nov 2004 21:27:17 +0000 (GMT) X-OB-Received: from unknown (205.158.62.156) by wfilter.us4.outblaze.com; 28 Nov 2004 21:27:17 -0000 Received: by ws5-7.us4.outblaze.com (Postfix, from userid 1001) id 4590B2B2B86; Sun, 28 Nov 2004 21:27:17 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [66.91.118.223] by ws5-7.us4.outblaze.com with http for sam124@operamail.com; Sun, 28 Nov 2004 22:27:17 +0100 From: "Sam Lauber" To: gcc@gcc.gnu.org Date: Sun, 28 Nov 2004 21:40:00 -0000 Subject: Useless assembly X-Originating-Ip: 66.91.118.223 X-Originating-Server: ws5-7.us4.outblaze.com Message-Id: <20041128212717.4590B2B2B86@ws5-7.us4.outblaze.com> X-SW-Source: 2004-11/txt/msg01088.txt.bz2 When I run GCC 3.4.3 on this code: #include =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 int main(void) { printf("Hello World!\n"); return 0; } =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 it generates the assembly code (this is i686 assembly) .file "test.c" .section .rodata .LC0: .string "Hello World!\n" .text .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp movl $0, %eax addl $15, %eax addl $15, %eax shrl $4, %eax sall $4, %eax subl %eax, %esp movl $.LC0, (%esp) call printf movl $0, %eax leave ret .size main, .-main .section .note.GNU-stack,"",@progbits .ident "GCC: (GNU) 3.4.3" =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 By hand-optimizing the assembly, I made this: .LC0: .string "Hello World!\n" .globl main .type main, @function main: pushl %ebp movl %esp, %ebp movl $.LC0, (%esp) call printf leave It worked the exact same. Clearly a lot was unnessecary. Removing "call pri= ntf" or "movl $.LC0, (%esp)" caused it not to print "Hello World!". Removin= g ".globl main" caused the linker to fail with an undefined reference to ma= in. Removing anything else caused it to print Hello World and then generate= a segmentation fault. Optimizing it at -O3 (which I'm sure includes SSA, D= CE, and CCP) just made the compilation take longer and generate more assemb= ly then the first time. If someone could just automate removing that code i= n cc1, it would probably mean a lot of optimization. Also, when I just comp= iled a "return 0;", I would expect that to just generate main and the instr= uction "ret" (or is it "retn?"). Instead, it generated a lot of extra instr= uctions, then finally "ret". Clearly this is unsatisfactory. It makes cc1, = as, and ld slower because they have to compile, assemble, and link more ins= tructions. Each extra instruction makes a compilation time penalty of -3 an= d a runtime penalty of -1. At least that could be put onto DCE. If extra co= de gets generated by cc1, as and ld can't optimize it. Samuel Lauber --=20 _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. =46rom your mailbox to local or overseas cell phones. Powered by Outblaze