public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Bernd Schmidt <bernds@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: don't force debug insns after their PREV_INSNs
Date: Mon, 09 Apr 2012 06:51:00 -0000	[thread overview]
Message-ID: <orbon1e6v2.fsf@livre.localdomain> (raw)
In-Reply-To: <4DE927AB.3030905@codesourcery.com> (Bernd Schmidt's message of	"Fri, 03 Jun 2011 20:27:55 +0200")

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Jun  3, 2011, Bernd Schmidt <bernds@codesourcery.com> wrote:

> On 06/03/2011 04:47 PM, Alexandre Oliva wrote:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=677681 can be
>> “fixed” by disabling the artificial dependency of a debug insn on its
>> previous insn.
>> 
>> 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 “in place”.
>> 
>> 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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vta-sched-debug-without-dep-on-prev-bz677681.patch --]
[-- Type: text/x-diff, Size: 1103 bytes --]

for  gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* 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
     {

[-- Attachment #3: Type: text/plain, Size: 258 bytes --]



-- 
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

  reply	other threads:[~2012-04-09  6:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-03 14:51 Alexandre Oliva
2011-06-03 18:29 ` Bernd Schmidt
2012-04-09  6:51   ` Alexandre Oliva [this message]
2012-06-13  8:08     ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orbon1e6v2.fsf@livre.localdomain \
    --to=aoliva@redhat.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).