From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28364 invoked by alias); 20 Oct 2002 21:55:42 -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 28349 invoked from network); 20 Oct 2002 21:55:37 -0000 Received: from unknown (HELO uni-sb.de) (134.96.252.33) by sources.redhat.com with SMTP; 20 Oct 2002 21:55:37 -0000 Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.12.6/2002101000) with ESMTP id g9KLtaL7025292 for ; Sun, 20 Oct 2002 23:55:36 +0200 (CEST) Received: from mail.cs.uni-sb.de (IDENT:VAXDePru++xEf4zIZQeyvqG7SIOwFMMU@mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.12.1/2002101000) with ESMTP id g9KLtZf26478 for ; Sun, 20 Oct 2002 23:55:36 +0200 (CEST) Received: from ps.uni-sb.de (grizzly.ps.uni-sb.de [134.96.186.68]) by mail.cs.uni-sb.de (8.12.6/2002101500) with ESMTP id g9KLtYoW029466 for ; Sun, 20 Oct 2002 23:55:34 +0200 (CEST) X-Authentication-Warning: email: Host grizzly.ps.uni-sb.de [134.96.186.68] claimed to be ps.uni-sb.de Received: from elk.ps.uni-sb.de.ps.uni-sb.de (elk.ps.uni-sb.de [134.96.186.151]) by ps.uni-sb.de (8.11.6/8.11.0) with ESMTP id g9KLtYO24329 for ; Sun, 20 Oct 2002 23:55:34 +0200 To: gcc@gcc.gnu.org Subject: abysmal code generated by gcc 3.2 From: Denys Duchier Date: Mon, 21 Oct 2002 00:56:00 -0000 Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg01226.txt.bz2 my application is the implementation of a virtual machine for an emulated programming language. Switching from gcc 2.95.x to 3.2 brought a few expected pains due to the change in data layout, but the major issue is that gcc 3.2 produces extremely poor code for my application on x86 (also on others, but I have not measured those personally). Measuring just the impact on the main emulator loop (which uses the classical threaded code technique, i.e. jumps to first class labels) I found that the emulator was slowed down by a FACTOR of 8.27. Looking at the generated assembly code, it is clear that the 3.2 compiler expends a lot of effort trying to keep a certain set of values in registers. On x86, this is a horrible policy (especially in a threaded code interpretation loop). Part of the problem comes from an interaction with inlining. I turned inlining off for a couple of non-critical functions which were exposing values that the compiler ended up trying to keep in registers, and I declared one variable volatile (much better results than trying to switch off gcse). This got me to only a factor 1.37 slowdown :-) ... measured on basically pure emulated recursion (i.e. the speed of looping while doing nothing else). Which of course still sucks majorly since this is the MAIN emulator loop (and since _every_ part of the implementation has been sizeably slowed down... aargh!) Here is an example of what I still cannot get rid of. Here is the code produced by gcc 2.95.x for the MOVEXX instruction: #APP MOVEXX: #NO_APP movl 4(%ebp),%edx movl 8(%ebp),%eax addl $12,%ebp movl (%edx),%edx movl %edx,(%eax) jmp *(%ebp) Here is the code produced by gcc 3.2: #APP MOVEXX: #NO_APP movl 4(%ebp), %esi movl 8(%ebp), %eax addl $12, %ebp # PC movl (%esi), %ebx movl _oz_heap_end, %esi # _oz_heap_end movl %ebx, (%eax) movl _oz_heap_cur, %ebx # _oz_heap_cur, sPointer movl 480(%esp), %eax # CAP movl am+52, %ecx # ._currentOptVar, movl am+28, %edx # .statusReg, leal 12(%eax), %edi # jmp *(%ebp) # * PC To my uneducated eye, it looks like gcc is now trying very hard to keep a bunch of values in registers. Every emulated instruction is like that, thus resulting in considerable overhead. I tried to declare _oz_heap_end and _oz_heap_cur volatile, but, curiously, that had no effect on this particular code generation. I am at my wits ends. Can anyone help? (I realize that my application is atypical). Cheers, PS: the compiler options used for the emulator file are: -fno-exceptions -O3 -pipe -fstrict-aliasing -march=pentium -mcpu=pentiumpro -fomit-frame-pointer -- Dr. Denys Duchier Denys.Duchier@ps.uni-sb.de Forschungsbereich Programmiersysteme (Programming Systems Lab) Universitaet des Saarlandes, Geb. 45 http://www.ps.uni-sb.de/~duchier Postfach 15 11 50 Phone: +49 681 302 5618 66041 Saarbruecken, Germany Fax: +49 681 302 5615