From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30045 invoked by alias); 9 Apr 2012 06:51:04 -0000 Received: (qmail 30021 invoked by uid 22791); 9 Apr 2012 06:51:02 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,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:50:49 +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 q396ojqR026518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Apr 2012 02:50:45 -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 q396oh1f018289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2012 02:50:45 -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 q396ohAA010120; Mon, 9 Apr 2012 03:50:43 -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 q396ogG2002960; Mon, 9 Apr 2012 03:50:42 -0300 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id q396ofkY002958; Mon, 9 Apr 2012 03:50:41 -0300 From: Alexandre Oliva To: Bernd Schmidt Cc: gcc-patches@gcc.gnu.org Subject: Re: don't force debug insns after their PREV_INSNs References: <4DE927AB.3030905@codesourcery.com> Date: Mon, 09 Apr 2012 06:51:00 -0000 In-Reply-To: <4DE927AB.3030905@codesourcery.com> (Bernd Schmidt's message of "Fri, 03 Jun 2011 20:27:55 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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-04/txt/msg00418.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 1461 On Jun 3, 2011, Bernd Schmidt wrote: > On 06/03/2011 04:47 PM, Alexandre Oliva wrote: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D677681 can be >> =E2=80=9Cfixed=E2=80=9D by disabling the artificial dependency of a debu= g insn on its >> previous insn. >>=20 >> Debug insns will often depend on their prevs anyway, in a use/def >> relationship, but if the def was (re)moved or the use was reset, this >> artificial dep helped keep the debug insn =E2=80=9Cin place=E2=80=9D. >>=20 >> Being a very imperfect heuristic, it's not clear that it helps more than >> it harms. Thoughts? Regstrapped on x86_64-linux-gnu and >> i686-linux-gnu. > Can you explain a little more clearly what the problem is? The RH > bugzilla isn't really clear. The problem here is that a nondebug insn may be moved ahead of a useful debug insn and clobber one of its inputs, rendering it useless, when there's no good reason for the debug insn to be kept in place, other than an accidental dependency on the previous insn when it happens to be unrelated with the debug insn. Removing the extraneous dependency, that was thought to be a way to reduce movement of debug insns, improves on this problem. It's not clear that this artificial dependency really does any good, since odds are that that previous insn may be pulled ahead anyway, in which case so will debug insn (unless that would fail other of its deps, of course) Retested. Ok? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=vta-sched-debug-without-dep-on-prev-bz677681.patch Content-length: 1103 for gcc/ChangeLog from Alexandre Oliva * sched-deps.c (sched_analyze_insn): Don't force debug insns to follow their original predecessors. Index: gcc/sched-deps.c =================================================================== --- gcc/sched-deps.c.orig 2012-02-25 09:45:31.749795611 -0200 +++ gcc/sched-deps.c 2012-04-08 02:10:39.710573253 -0300 @@ -2988,18 +2988,6 @@ sched_analyze_insn (struct deps_desc *de reg_last->uses = alloc_INSN_LIST (insn, reg_last->uses); } CLEAR_REG_SET (reg_pending_uses); - - /* Quite often, a debug insn will refer to stuff in the - previous instruction, but the reason we want this - dependency here is to make sure the scheduler doesn't - gratuitously move a debug insn ahead. This could dirty - DF flags and cause additional analysis that wouldn't have - occurred in compilation without debug insns, and such - additional analysis can modify the generated code. */ - prev = PREV_INSN (insn); - - if (prev && NONDEBUG_INSN_P (prev)) - add_dependence (insn, prev, REG_DEP_ANTI); } else { --=-=-= Content-length: 258 -- 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 --=-=-=--