From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1949 invoked by alias); 10 Dec 2001 07:07:13 -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 1393 invoked from network); 10 Dec 2001 07:05:10 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 10 Dec 2001 07:05:10 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id XAA14373; Sun, 9 Dec 2001 23:04:09 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma014349; Sun, 9 Dec 01 23:03:52 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.27.78]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id fBA73xS13098; Sun, 9 Dec 2001 23:03:59 -0800 (PST) From: Linus Torvalds Received: (from torvalds@localhost) by penguin.transmeta.com (8.11.2/8.7.3) id fBA6wEh13767; Sun, 9 Dec 2001 22:58:14 -0800 Date: Sun, 09 Dec 2001 23:29:00 -0000 Message-Id: <200112100658.fBA6wEh13767@penguin.transmeta.com> To: rth@redhat.com, gcc@gcc.gnu.org Subject: Re: Optimizations on long long multiply/divide on PowerPC32 don't work Newsgroups: linux.egcs In-Reply-To: <20011207164904.C16375@redhat.com> References: <3C115A53.2070206@acm.org> Organization: Cc: X-SW-Source: 2001-12/txt/msg00468.txt.bz2 In article <20011207164904.C16375@redhat.com> you write: >On Fri, Dec 07, 2001 at 06:09:55PM -0600, Corey Minyard wrote: >> 1) Add __divdi3 to the linux kernel. I don't really think this is a >> good idea, and it shouldn't be required. > >Yes it should. I've long considered it a bug that Linux >didn't link against libgcc. I'm sorry you feel that way, but what the gcc team has done to libgcc has only made me _more_ convinced that not linking against that steenking heap of *** is a really good idea.. Not linking against libgcc has found several problems in gcc. Ranging from missing totally obvious optimizations (and yes, I consider that a _bug_, even though I know that some gcc people think that performance is secondary), to horrible mis-features with exception handling. For example, it was the absense of libgcc that made us aware that the kernel had to use magic (and largely undocumented) gcc command line flags to make sure that gcc didn't try to insert its totally broken exception handling code. Similarly, it is the lack of libgcc that was really helpful in pointing out code where some people started using 64-bit arithmetic without realizing just how slow it would be. In fact, it was this very missing __divdi3 thing that showed that you shouldn't try to do 64-bit divides, when you can, by thinking about the problem for five minutes, do it about a hundred times faster by just keeping a 32-bit index and offset pair. Think about it this way: "libgcc" is the place where code goes to die. It is, by _design_, the place where gcc developers put the code that is so cr*p that it cannot really be inlined. Avoiding it is a _good_ thing, as it forces the kernel to step carefully around issues where gcc has problems. The fact that gcc cannot do a 64-bit divide by a constant is a gcc deficiency. But it is NOT cause for including crap in the kernel. Linus