From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27977 invoked by alias); 25 Nov 2007 00:02:23 -0000 Received: (qmail 27969 invoked by uid 22791); 25 Nov 2007 00:02:22 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 25 Nov 2007 00:02:18 +0000 Received: by py-out-1112.google.com with SMTP id a29so581524pyi for ; Sat, 24 Nov 2007 16:02:16 -0800 (PST) Received: by 10.64.153.4 with SMTP id a4mr2139552qbe.1195948935763; Sat, 24 Nov 2007 16:02:15 -0800 (PST) Received: by 10.65.203.6 with HTTP; Sat, 24 Nov 2007 16:02:15 -0800 (PST) Message-ID: <84fc9c000711241602s5d541755h158d6507de25f3f6@mail.gmail.com> Date: Sun, 25 Nov 2007 14:46:00 -0000 From: "Richard Guenther" To: "Alexandre Oliva" Subject: Re: Designs for better debug info in GCC Cc: "Bernd Schmidt" , "Richard Kenner" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org, iant@google.com, mark@codesourcery.com, stevenb.gcc@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <571f6b510711121208m2bf7c77fp884f52d458df118b@mail.gmail.com> <571f6b510711231556o439e7bbek9ab4855079bab51d@mail.gmail.com> <10711240545.AA22279@vlsi1.ultra.nyu.edu> <47484BA4.5080906@t-online.de> <84fc9c000711241248q258c987ay904205559dd766c0@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg01314.txt.bz2 On Nov 25, 2007 12:28 AM, Alexandre Oliva wrote: > On Nov 24, 2007, "Richard Guenther" wrote: > > > Generated code shouldn't change if we allocate extra DECL_UIDs, but > > only possibly if we change DECL_UID ordering. (If that is the > > problem, as I remember your analysis) > > That is indeed the problem, but I'm not sure your requirement is > feasible. If we permit DECL_UID divergence, it means we can't use > DECL_UID for hashing any more. Since they already stand for hashable > proxies for the decl pointers, I don't see what we'd gain by > introducing yet another hashable uid that's stable across -g. > > What do you suggest us to use for hashing? Or do you suggest us to do > away with hashing and use sorted set or map data structures? No, hashing is fine, but doing walks over a hashtable when your algorithm depends on ordering is not. I have patches to fix the instance of walking over all referenced vars. Which is in the case of UIDs using bitmaps and a walk over a bitmap (which ensures walks in UID order). Richard.