From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-106317-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30891 invoked by alias); 7 Dec 2004 13:01:49 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 30693 invoked from network); 7 Dec 2004 13:01:41 -0000
Received: from unknown (HELO Cantor.suse.de) (195.135.220.2)
  by sourceware.org with SMTP; 7 Dec 2004 13:01:41 -0000
Received: from extimap.suse.de (extimap.suse.de [195.135.220.6])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by Cantor.suse.de (Postfix) with ESMTP id A534611DB4E2;
	Tue,  7 Dec 2004 14:01:40 +0100 (CET)
Received: from extimap.suse.de (extimap.suse.de [195.135.220.6])
	by extimap.suse.de (Postfix) with ESMTP
	id 466FB127F68; Tue,  7 Dec 2004 14:01:36 +0100 (CET)
Message-ID: <4376440.1102424496286.SLOX.WebMail.wwwrun@extimap.suse.de>
Date: Tue, 07 Dec 2004 13:01:00 -0000
From: Steven Bosscher <stevenb@suse.de>
To: Daniel Towner <daniel.towner@picochip.com>
Subject: Re: Incorrect DFA scheduling of output dependency.
Cc: Vladimir Makarov <vmakarov@redhat.com>, gcc@gcc.gnu.org,
	Nathan Sidwell <nathan@codesourcery.com>
In-Reply-To: <41B58D07.7020306@picochip.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Operating-System: Linux 2.4.21-251-smp i386 (JVM 1.3.1_04)
Organization: SuSE Linux AG
References: <41B442B7.9020408@picochip.com> <4526639.1102336240386.SLOX.WebMail.wwwrun@extimap.suse.de> <41B4886C.6020409@picochip.com> <41B49276.9030603@redhat.com> <41B58D07.7020306@picochip.com>
X-SW-Source: 2004-12/txt/msg00279.txt.bz2

On Dec 07, 2004 11:59 AM, Daniel Towner <daniel.towner@picochip.com> wrote:

> Vlad, et al.,
> 
> >> I was wrong here. The instruction sequence is actually a data 
> >> (read-after-write) dependency, not an output dependency 
> >> (write-after-write). However, the relevent portion of the scheduler 
> >> dump is as follows:
> >>
> >> (note 82 147 64 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> >>
> >> (insn:TI 64 82 150 2 (set (reg/v:HI 4 R4 [orig:25 rdIndex ] [25])
> >>        (const_int 0 [0x0])) 15 {movhi} (nil)
> >>    (nil))
> >>
> >> (note 150 64 133 2 NOTE_INSN_LOOP_END)
> >>
> >> (insn 133 150 135 2 (set (reg:HI 5 R5 [33])
> >>        (ashift:HI (reg/v:HI 4 R4 [orig:25 rdIndex ] [25])
> >>            (const_int 2 [0x2]))) 48 {ashlhi3} (insn_list:REG_DEP_ANTI 
> >> 64 (nil))
> >>    (expr_list:REG_EQUAL (ashift:HI (reg/v:HI 4 R4 [orig:25 rdIndex ] 
> >> [25])
> >>            (const_int 2 [0x2]))
> >>        (nil)))
> >>
> >> Does this state that insn 133 is anti-dependent on insn 64?
> >
> I've discovered that the anti-dependency is inserted by sched_analyze. 
> It occurs because of the NOTE_INSN_LOOP_END between the two instructions 
> above. This note introduces a move barrier between the instructions, 
> which is intended to prevent the two instructions being reordered. 


Can someone explain please why we have loop notes in the middle of
a basic block?

Gr.
Steven