From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27569 invoked by alias); 16 Oct 2004 18:14:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27562 invoked from network); 16 Oct 2004 18:14:13 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 16 Oct 2004 18:14:13 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i9GIIlUC014286 for ; Sat, 16 Oct 2004 11:18:47 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Sat, 16 Oct 2004 11:14:13 -0700 Received: from [17.219.196.201] ([17.219.196.201]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i9GIEAfe020900; Sat, 16 Oct 2004 11:14:11 -0700 (PDT) In-Reply-To: <20041016103712.GA31909@devserv.devel.redhat.com> References: <20041016094708.GZ31909@devserv.devel.redhat.com> <20041016103712.GA31909@devserv.devel.redhat.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C5EF2C1-1F9F-11D9-8C49-000A95BCF344@apple.com> Content-Transfer-Encoding: 7bit Cc: GCC Patches From: Matt Austern Subject: Re: [Committed] Use special-purpose hash table to speed up walk_tree Date: Sat, 16 Oct 2004 18:29:00 -0000 To: Jakub Jelinek X-SW-Source: 2004-10/txt/msg01341.txt.bz2 On Oct 16, 2004, at 3:37 AM, Jakub Jelinek wrote: > On Sat, Oct 16, 2004 at 05:47:08AM -0400, Jakub Jelinek wrote: >> But on x86-64-redhat-linux essentially makes even bootstrap impossible >> (well, I have killed it after it spent more than 10 minutes compiling >> insn-recog or insn-attrtab by stage1/cc1). >> hash1's distribution is less than perfect. > > For the hash function I'm trying these patches now: > > (both do the same, not sure if the first one is ok regarding absolute > portability). If it were me I'd probably use the first patch, to make absolutely sure we're doing nothing but multiplication by a compile-time constant. Probably the optimizer is smart enough to optimize all away the extra stuff in the second version of the patch, but I'd rather not count on that in code that really is time critical. --Matt