From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11977 invoked by alias); 8 Jun 2006 15:12:20 -0000 Received: (qmail 11416 invoked by uid 48); 8 Jun 2006 15:11:47 -0000 Date: Thu, 08 Jun 2006 15:24:00 -0000 Message-ID: <20060608151147.11415.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "sje at cup dot hp dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-06/txt/msg00943.txt.bz2 List-Id: ------- Comment #13 from sje at cup dot hp dot com 2006-06-08 15:11 ------- The proposed patch does fix the compilation time problem on hppa64-hp-hpux11.11 but I am confused about how the cache works. Without the patch, the compile takes 15 to 20 minutes but I do wind up generating a sequence of instructions instead of a call to __divdi3. With the patch, I get a very fast compilation, but I also get a call to __divdi3 instead of the code sequence. Why does caching results change the behaviour? Caches (in general) should speed things up by saving previous/intermediate results, but shouldn't change the ultimate answer. This seems to be doing something different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733