From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27636 invoked by alias); 24 Nov 2007 15:18:23 -0000 Received: (qmail 27624 invoked by uid 22791); 24 Nov 2007 15:18:22 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Nov 2007 15:18:16 +0000 Received: by py-out-1112.google.com with SMTP id a29so360630pyi for ; Sat, 24 Nov 2007 07:18:14 -0800 (PST) Received: by 10.65.81.10 with SMTP id i10mr1194955qbl.1195917493823; Sat, 24 Nov 2007 07:18:13 -0800 (PST) Received: by 10.65.203.6 with HTTP; Sat, 24 Nov 2007 07:18:13 -0800 (PST) Message-ID: <84fc9c000711240718y4a28cacaia2ec74f71bc79b52@mail.gmail.com> Date: Sat, 24 Nov 2007 20:21:00 -0000 From: "Richard Guenther" To: "Alexandre Oliva" Subject: Re: Designs for better debug info in GCC Cc: "Steven Bosscher" , "Mark Mitchell" , "Ian Lance Taylor" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org 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> <571f6b510711240227r5c5b97a1gb57972621e27e3a5@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/msg01291.txt.bz2 On Nov 24, 2007 4:00 PM, Alexandre Oliva wrote: > On Nov 24, 2007, "Steven Bosscher" wrote: > > > And it has to handle this new case everywhere. > > I've already explained why this isn't true. It's not even close to > being true. In fact, I've chosen this representation *precisely* > because I reasoned it would lead to the least global impact. Of > course you can refuse to believe that and point at the changes I had > to make as alleged counter-proof, failing to notice how many other > locations I haven't had to change and that just work because adjusting > other instructions after transformations is precisely what all > transformation passes already do. It also makes some things easier - for example during inlining of a function body we re-map all DECLs in the inlined copy. With an on-the-side representation you have to ensure to make the same mapping explicitly, with DEBUG_INSNs the mapping is automatically done during the copying of the IL. A similar problem with using SSA_NAME definition points to store information is using the renamer to rename a variable that already has SSA_NAMES (which is IMHO bogus, as we do not detect the errorneous case of overlapping life-ranges - but ignore that for now) - in this case you need some magic to transfer the on-the-side debug information from the old SSA_NAMEs to the new ones (where possible). Just to mention a few problems we are running into ;) Richard.