From patchwork Mon Apr 9 06:53:14 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 151413 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 7F95DB7011 for ; Mon, 9 Apr 2012 16:53:41 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1334559221; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=9KcFCqUYE5gdEpInfjvd qKgASY0=; b=xYGedejsELPYPt6ZrJJAi/8Lqlf58P0ND4hj9EfXU9Y/lJztBW+f KcM21bOMHA+hRdf1umHNIeerEW+Lrj5+9Bju0OE7fz7gleHguuIrekQwwVbPHOlC N232SIrfYVOaXRlDDtrcC9Ss17+PR8KaXL4MIkBwSLQdcnRhFEsUcds= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Received:From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=GxgJAwlhLhJQrLNVdQ3A17bZH2+cYP7qo8pqUS2tvV3aODA/AChQsL6hEenyt5 1RsM1jWpN1hz8TZhwCVo12pqN78W+grPozhWg0tbvfGbXKZkzEI+es+HDRzXlCo5 ZftS65Q8LPErYPc9NoEtNujzS6P9FLYRG8CtL3Ar/uLe8=; Received: (qmail 30989 invoked by alias); 9 Apr 2012 06:53:34 -0000 Received: (qmail 30979 invoked by uid 22791); 9 Apr 2012 06:53:32 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, TW_DD, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS 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, 09 Apr 2012 06:53:19 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q396rIpF019222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Apr 2012 02:53:18 -0400 Received: from freie.oliva.athome.lsd.ic.unicamp.br (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q396rHUT018830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 02:53:18 -0400 Received: from livre.localdomain (livre.oliva.athome.lsd.ic.unicamp.br [172.31.160.2]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.5/8.14.5) with ESMTP id q396rGBD010192; Mon, 9 Apr 2012 03:53:16 -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 q396rGNr002998; Mon, 9 Apr 2012 03:53:16 -0300 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id q396rEjb002996; Mon, 9 Apr 2012 03:53:14 -0300 From: Alexandre Oliva To: Revital1 Eres Cc: Ayal Zaks , gcc-patches@gcc.gnu.org Subject: Re: debug insns in SMS References: Date: Mon, 09 Apr 2012 03:53:14 -0300 In-Reply-To: (Revital's message of "Wed, 4 May 2011 12:31:14 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On May 4, 2011, Revital1 Eres wrote: > Hello Alexandre >> I think this will restore proper functioning to SMS in the presence of >> debug insns. A while ago, we'd never generate deps of non-debug insns >> on debug insns. I introduced them to enable sched to adjust (reset) >> debug insns when non-debug insns were moved before them. I believe it >> is safe to leave them out of the SCCs. Even though this will end up >> causing some loss of debug info, that's probably unavoidable, and the >> end result after this change is pobably the best we can hope for. Your >> thoughts? > Thanks for the patch! > I actually discussed this issue with Ayal yesterday. > Ayal also suggested to reconsider the edges that are created in > the DDG between real instructions and debug_insns. Currently, we create > bidirectional anti deps edges between them. This leads to the problem you > were trying to solve in the current patch (described below) where these > extra edges influence the construction of the strongly connected component > and the code generated with and w\o -g. Your patch seems to solve this > problem. > However I can not approve it as I'm not the maintainer (Ayal is). Ping? (Retested on x86_64-linux-gnu and i686-pc-linux-gnu) for gcc/ChangeLog from Alexandre Oliva * ddg.c (build_intra_loop_deps): Discard deps of nondebug on debug. Index: gcc/ddg.c =================================================================== --- gcc/ddg.c.orig 2012-01-04 21:06:38.000000000 -0200 +++ gcc/ddg.c 2012-04-08 02:10:44.711511989 -0300 @@ -532,7 +532,12 @@ build_intra_loop_deps (ddg_ptr g) FOR_EACH_DEP (dest_node->insn, SD_LIST_BACK, sd_it, dep) { - ddg_node_ptr src_node = get_node_of_insn (g, DEP_PRO (dep)); + ddg_node_ptr src_node; + + if (DEBUG_INSN_P (DEP_PRO (dep)) && !DEBUG_INSN_P (dest_node->insn)) + continue; + + src_node = get_node_of_insn (g, DEP_PRO (dep)); if (!src_node) continue;