From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8033 invoked by alias); 6 Jun 2011 07:11:46 -0000 Received: (qmail 8025 invoked by uid 22791); 6 Jun 2011 07:11:44 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,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, 06 Jun 2011 07:11:28 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p567B6wg006492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jun 2011 03:11:06 -0400 Received: from freie.oliva.athome.lsd.ic.unicamp.br (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p567B42K012478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2011 03:11:06 -0400 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.4/8.14.4) with ESMTP id p566JnWL029842; Mon, 6 Jun 2011 03:19:49 -0300 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p566Jmlk022517; Mon, 6 Jun 2011 03:19:48 -0300 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id p566Jlbu022516; Mon, 6 Jun 2011 03:19:47 -0300 From: Alexandre Oliva To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: Re: fix left-over debug insns in DCE References: <201106021718.42782.ebotcazou@adacore.com> <201106031258.13095.ebotcazou@adacore.com> Date: Mon, 06 Jun 2011 07:11:00 -0000 In-Reply-To: <201106031258.13095.ebotcazou@adacore.com> (Eric Botcazou's message of "Fri, 3 Jun 2011 12:58:12 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-06/txt/msg00360.txt.bz2 On Jun 3, 2011, Eric Botcazou wrote: > Does the same logic need to be replicated in all passes that do? On > the other hand, these passes call into DF when they remove insns, so > DF is a central place here. I went over (again?) a number of passes that call delete_insn directly or indirectly. The problem is that, at that point, it's not possible to tell whether: - equivalent DEFs are going to be re-emitted at the same place (say, a split), so debug insns are to be left alone, - whether they're being re-emitted elsewhere (say a move), so *some* debug insns may have to be adjusted - whether DEFs are really being removed, in which case debug temps may have to be emitted; and the uses, adjusted; and other reaching defs also followed by binding of the same debug temps - whether many chained insns are being deleted (say an entire BB, or part of a BB found to be shared between multiple BBs), in which case debug insns may have to be left alone or adjusted depending on the CFG adjustments to be made later Given this analysis, I'm still of the opinion that passes that remove insns that may be used by debug insns ought to decide on their own how to make the adjustments (or not), as they currently do, but that we should have better shared infrastructure to propagate defs-to-be-removed, which is currently done in an ad hoc manner in several passes. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer