From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17931 invoked by alias); 6 Apr 2010 06:36:09 -0000 Received: (qmail 17906 invoked by uid 22791); 6 Apr 2010 06:36:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Apr 2010 06:36:01 +0000 Received: from sunsite.mff.cuni.cz (localhost [127.0.0.1]) by sunsite.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id o366Zwiu012486; Tue, 6 Apr 2010 08:35:59 +0200 Received: (from jj@localhost) by sunsite.mff.cuni.cz (8.14.3/8.14.3/Submit) id o366Zwkv012485; Tue, 6 Apr 2010 08:35:58 +0200 Date: Tue, 06 Apr 2010 06:36:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: Alexandre Oliva , GCC Subject: Re: VTA/debugging vs reload-v2 Message-ID: <20100406063558.GL3601@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <4BBA11BC.4060300@redhat.com> <4BBA6FCB.10302@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBA6FCB.10302@redhat.com> User-Agent: Mutt/1.5.19 (2009-01-05) 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/msg00073.txt.bz2 On Mon, Apr 05, 2010 at 05:18:35PM -0600, Jeff Law wrote: >> 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? Yes, it can be arbitrary valid RTL (validate_change/verify_changes allow any changes to DEBUG_INSNs). The problematic stuff is mainly when some RTL with non-VOIDmode (REG, MEM etc.) needs to be replaced with a VOIDmode constant - in that case simplify_replace_{,fn_}rtx needs to be used to change the invalid RTL into valid. We don't want say (zero_extend:DI (const_int 6)) or (subreg:QI (const_int 12345678) 4) etc. staying around in the DEBUG_INSNs. But I guess for reload2 you'll be changing just REGs and MEMs to other REGs and MEMs - in that case just a replacement through say for_each_rtx is possible too. Jakub