From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32438 invoked by alias); 14 Jul 2009 05:20:34 -0000 Received: (qmail 32423 invoked by uid 22791); 14 Jul 2009 05:20:32 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Jul 2009 05:20:25 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n6E5KN4f014471; Tue, 14 Jul 2009 01:20:23 -0400 Received: from omfg.slc.redhat.com (vpn-240-90.phx2.redhat.com [10.3.240.90]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6E5KJJ8002001; Tue, 14 Jul 2009 01:20:21 -0400 Message-ID: <4A5C15C0.3000004@redhat.com> Date: Tue, 14 Jul 2009 05:20:00 -0000 From: Jeff Law User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Steven Bosscher CC: Kaz Kojima , gcc@gcc.gnu.org Subject: Re: A question about df_get_live_in References: <20090714.064618.217955193.kkojima@rr.iij4u.or.jp> <571f6b510907131507y6824fe4n6932b3ea26e85527@mail.gmail.com> In-Reply-To: <571f6b510907131507y6824fe4n6932b3ea26e85527@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00233.txt.bz2 Steven Bosscher wrote: > On Mon, Jul 13, 2009 at 11:46 PM, Kaz Kojima wrote: > >> Hi, >> >> I hope DF/middle-end experts will comment about this. >> >> PR target/40710 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710 >> >> is a wrong code problem on SH. A delayed slot of a conditional >> branch insn is wrongly filled with an insn changing stack pointer >> in the failing case. I've tried to see what is going on. >> > > You found out why the dbr-sched pass (reorg.c) needs a rewrite so > badly. DF needs a CFG, and reorg.c refuses to maintain a valid CFG. In > other words, it just doesn't work very well together. See PR39938, > PR40086, etc... > I think most of reorg's issues go away if it were changed to use the same dependency information that we build for the schedulers rather than trying to build it in an ad-hoc fashion on the fly. As an added benefit it would be a hell of a lot faster. Jeff