From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8089 invoked by alias); 5 Apr 2010 23:18:47 -0000 Received: (qmail 7954 invoked by uid 22791); 5 Apr 2010 23:18:46 -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 23:18:40 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o35NIc6x020821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Apr 2010 19:18:39 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o35NIbxH030977; Mon, 5 Apr 2010 19:18:37 -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 o35NIabv003582; Mon, 5 Apr 2010 19:18:36 -0400 Message-ID: <4BBA6FCB.10302@redhat.com> Date: Mon, 05 Apr 2010 23:18: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: Re: VTA/debugging vs reload-v2 References: <4BBA11BC.4060300@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/msg00070.txt.bz2 On 04/05/10 14:32, Alexandre Oliva wrote: > On Apr 5, 2010, Jeff Law wrote: > > >> 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 can think of 3 points that you might have to be concerned about: > > 1. Don't pay attention to debug insns when computing the live ranges. > You don't want to take debug insns into account when making decisions > about transformations to executable code. > Right. I already figured this one out the hard way a while back. > 2. When renaming references from P to P' in a region, do take debug > insns in the region into account, renaming references in debug insns as > you would in any other insn. > OK. So presumably the 2nd argument in a VAR_LOCATION can be any rtl expression? Meaning I have to parse it looking for things that need changing? Right? > 3. If any debug insns ended up outside any of the regions determined > without taking debug insns into account, you may have to patch things up > so that they don't remain as dangling pointers to P. From your > description above, it appears to me that replacing such remaining > references to P in debug insns with the memory slot assigned to it would > be the right thing to do. > Makes sense, though I'm not terribly familiar with how this could happen, replacing P with its memory location seems to be the right thing to do. I guess a single pass through the entire function's RTL looking for dangling references in debug insns is in order. Or I might be able to get away with changing regno_reg_rtx to point to the appropriate memref... hmmm. Everything you noted seems to be designed to keep the existing debug_insns updated -- under what circumstances are debug_insns created (which ought to give me a clue about whether or not I'm going to need to create new ones). > This should be all, and it's very much in line with “The Zen of VTA”: > disregard debug insns when deciding what to do, transform debug insns > just as you would regular insns, and patch up any debug insns left out > of the decisions you made. > FWIW, I don't see any references to debug_insn or var_location in gcc/doc/*.texi. Somehow I think this must be unintentional. Jeff