From owner-freebsd-hackers Thu Feb 13 20:48:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05544 for hackers-outgoing; Thu, 13 Feb 1997 20:48:52 -0800 (PST) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.155.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05537 for ; Thu, 13 Feb 1997 20:48:46 -0800 (PST) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id XAA16062; Thu, 13 Feb 1997 23:48:22 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id XAA18687; Thu, 13 Feb 1997 23:48:07 -0500 Date: Thu, 13 Feb 1997 23:48:07 -0500 Message-Id: <199702140448.XAA18687@jenolan.caipgeneral> From: "David S. Miller" To: hamby@aris.jpl.nasa.gov CC: asami@vader.cs.berkeley.edu, jmb@freefall.freebsd.org, hackers@FreeBSD.ORG In-reply-to: (message from Jake Hamby on Thu, 13 Feb 1997 20:17:38 -0800 (PST)) Subject: Re: Sun Workshop compiler vs. GCC? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Date: Thu, 13 Feb 1997 20:17:38 -0800 (PST) From: Jake Hamby Hmm, good point. I guess I meant that the commercial compilers seem to have MORE kinds of optimizations than GCC, and because they support relatively few targets, they can devote more time to optimizing each code generation back-end. I have been in fact been working with some people to encourage further work in this area, in particular: 1) Jakub Jelinek and myself have worked on what is termed "tail call" optimization, we call them sibling calls in the gcc implementation. This one is a huge win for many code sets which have a moderate to large stack call depth. It can eliminate entire local stack frames. As an easy example on the Sparc: extern int foo(int a); extern int bar(int b); static __inline__ int baz(int a, int b) { (void) foo(a); return bar(b); } static int func(int a, int b) { return baz(a, b); } gets turned into func: save %sp,-112,%sp call foo,0 mov %i0,%o0 call bar,0 restore %g0,%i1,%o0 (for those unfamiliar with Sparc, "save" allocates a register window and a stack frame, "restore" gives it back, Sparc also has branch/call delay slots) In that example the entire stack frame is given up in the delay slot of the call to bar(). If people think this is useless and cheezy, think again. Walk though your average kernel subsystem and see how many functions go: { if(args_invalid(args)) return -EFAULT; /* whatever */ if((file = file_from_fd(args)) == NULL) return -EBADF; inode = inode_from_file(file); return file->f_op->frobnicate(areg); } Also, networking stacks where layer upon layer gets called via a function ptr dereference as each packet walks up the various layers. Nine times out of ten this is the last thing the function in question does, and thus is subject to the optimizations just described as well. For example, in the Linux kernel sibling call optimization was shown to be applied over 1,000 times, approximately 186 of which were found to be in critical code paths. This was on the Sparc platform. Currently only the Sparc backend support for sibling calls are fully tested and working well in our patches, Intel, Alpha, and MIPS support for siblings calls are mostly done and should be ready soon. We are rather confident that this work will go all be in gcc-2.8.0. 2) I'm sure some people here know this, but there are people who have taken all of the Pentium optimization work on gcc done by the Intel compiler people way back, and are working on improving it. They are actively maintaining those changes, fixing bugs, and adding new optimizations as well. Also, one of the larger reasons that these changes never made it into the FSF gcc sources is that numerous generic changes were made to GCC which were not pretty at all. Cygnus and others are working on revamping some of the front end to back end architecture of GCC so that the types of things the Pentium optimizations needed are there, and are implemented cleanly. Also, the various optimizer bugs in GCC in the past have led people to be wary to use -O2 optimization, much less try additional optimization flags. I know about them, just about all of them are in the strength reduction pass. I am very familiar with the problematic bugs this layer has, and I have been actively trying to get people on the GCC development team to fix them. Almost all of these problems have to do with when a pointer comparison is converted into an integer invariant comparison, and vice versa. GCC in certain circumstances does not notice the change in signed'ness and thus produces incorrect code. In gcc-2.7.2.1, the strength reduction transformations that were known to lead to this situation were disabled entirely and in fact this fix was the entire reason for that release of gcc. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><