From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31142 invoked by alias); 5 Apr 2010 16:37:29 -0000 Received: (qmail 31122 invoked by uid 22791); 5 Apr 2010 16:37:25 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Apr 2010 16:37:20 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o35GbJ60002675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Apr 2010 12:37:19 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o35GbIMT013611; Mon, 5 Apr 2010 12:37:18 -0400 Received: from [172.17.64.15] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o35GbHg6029224; Mon, 5 Apr 2010 12:37:17 -0400 Message-ID: <4BBA11BC.4060300@redhat.com> Date: Mon, 05 Apr 2010 16:37:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 MIME-Version: 1.0 To: Alexandre Oliva CC: GCC Subject: VTA/debugging vs reload-v2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00063.txt.bz2 So as I mentioned in the meeting last week, I've largely been ignoring VTA (and more generally all debugging) issues with the reload work I'm doing. It's time to rectify that situation. For this phase of the work (range splitting) we only need to consider a few straightforward transformations to the RTL and how they impact the debugging information. The goal is to take a pseudo P and break its live range down into P1, P2, ... Pn where each of the sub-ranges are local to a region (right now a region is a straight line hunk of code with no join nodes -- not quite an extended basic block, but close). Outside these regions P lives in memory. Within each region the new pseudos P1, P2, ... Pn may be allocated to different hard registers. We accomplish this by emitting a load from memory into a new pseudo before the first use of P in a region and a store from the new pseudo back to memory after the last assignment to P within the region, then we rename all references from P to P'. It's marginally more complex, but I think for this discussion the other complexities can be ignored. After all regions have been processed, P is gone from the insn stream. Obviously P can be found in memory, P1, P2, ... Pn depending on precisely where we are in the code when the value is P is requested. I'm not terribly familiar with how dwarf2 represents variable ranges; I tend to think of this as P living in memory, except during the subregions where its in P1, P2, .. Pn. The sub-range pseudos P1, P2, .. Pn all point back to P via ORIGINAL_REGNO and all have the same reg_equiv_memory_loc. So, without having looked closely at dwarf2out.c (it hurts my head every time I try), is it likely we're going to need to be emitting new debug_insns to describe how to correctly find P in the different contexts? Thanks, Jeff