From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28707 invoked by alias); 6 Jan 2011 03:56:19 -0000 Received: (qmail 28697 invoked by uid 22791); 6 Jan 2011 03:56:18 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Jan 2011 03:56:14 +0000 From: "mark at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: meta-bug X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at codesourcery dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 06 Jan 2011 07:35:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00456.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #22 from Mark Mitchell 2011-01-06 03:55:40 UTC --- On 1/5/2011 5:36 AM, hubicka at gcc dot gnu.org wrote: > 40259 5.6000 cc1plus cc1plus > lookup_field_1 I've looked at this, in the distant past. I don't think the routine itself is *very* low-hanging fruit; it's already using an inline log n algorithm to find a field in most cases, and I bet that's as good as a hash table since n is generally relatively small. But, maybe "in most cases" is wrong; there is a slow-path, and we should confirm that most of the time is in the fast-path code. We could also try a bit of memoization; I wouldn't be surprised if we often lookup "x.y" several times in a row. More often, when I've looked at this kind of thing, though, I've concluded that the problem was that we were calling the routine too often, rather than the routine itself was too slow. Quite possibly we could improve algorithms that are using lookup_field_1 so that they didn't do so as often, by building caches or otherwise. For that, we'd need to look at the callers of lookup_field_1. So, in summary, I'd recommend three things: * Split lookup_field_1 into its fast-path and slow-path code so that we can profile it and figure out which code is taking up most of the time. * Assuming it's fast-path code, look at the frequent callers and think about how to optimize them.