From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25432 invoked by alias); 1 Nov 2012 15:04:36 -0000 Received: (qmail 25421 invoked by uid 22791); 1 Nov 2012 15:04:35 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Nov 2012 15:04:25 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id BD1FB298840; Thu, 1 Nov 2012 16:04:25 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wXneQYFk+cQ; Thu, 1 Nov 2012 16:04:25 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 8C9C229881C; Thu, 1 Nov 2012 16:04:25 +0100 (CET) From: Eric Botcazou To: Dehao Chen Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Reset source location for instructions moved out of its original residing basic block Date: Thu, 01 Nov 2012 15:04:00 -0000 Message-ID: <3309385.mAl1npuha0@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.16-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: References: <1826073.rNRXULK6yo@polaris> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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: 2012-11/txt/msg00051.txt.bz2 > For optimized code, there are many optimizations that can break > coverage info. Code motion is one of them. This patch actually tries > to fix the broken coverage info, as illustrated by the unittest. No, you seems to be misunderstanding what coverage means. For coverage to be correct, it is necessary that every insn generated for a particular source construct be associated with this source construct in the debug info. If you associate an insn with another source construct and it is executed, then you'll have the other source construct marked as covered, although it might not be actually covered during the execution. Code motion (as any other optimization passes) doesn't break coverage per se. For example, there is nothing wrong with hoisting a instruction out of a loop and keeping its source location if it is always executed; coverage info will be correct after the hoisting. In more complex cases, it might be necessary to clear the source location of the hoisted instruction. > If we clear the debug info for instructions moved to other BB, is it > acceptable? Yes, clearing is acceptable in principle, but should be done with extreme care since you drop information, so reorder_insns isn't the appropriate place as it's too big a hammer. FWIW, we have related patchlets in our internal tree, like: * loop-invariant.c (move_invariant_reg): Clear the locator of the invariant's insn after it has been moved. * tree-ssa-loop-im.c (move_computations_stmt): Clear the location and block of the invariant's statement after it has been moved. As for the more general problem of jumpiness in GDB for highly optimized code, this should be changed in GDB if your users cannot deal with it. The debug info describes the relationship between the generated code and the source code and, at high optimization levels, this relationship is not isomorphic at all. It's up to the source level debugger to filter out the non-isomorphic part of the mapping if it deems desirable to do so. -- Eric Botcazou