From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-104952-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12959 invoked by alias); 4 Nov 2004 01:44:54 -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 12915 invoked from network); 4 Nov 2004 01:44:52 -0000
Received: from unknown (HELO r-rr.iij4u.or.jp) (210.130.0.76)
  by sourceware.org with SMTP; 4 Nov 2004 01:44:52 -0000
Received: from localhost (frgw.3in.ne.jp [210.251.121.226])
	by r-rr.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id iA41icR17606;
	Thu, 4 Nov 2004 10:44:38 +0900 (JST)
Date: Thu, 04 Nov 2004 01:44:00 -0000
Message-Id: <20041104.104418.112602465.kkojima@rr.iij4u.or.jp>
To: aoliva@redhat.com
Cc: tm_gccmail@kloo.net, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org,
   joern.rennecke@st.com, naveens@noida.hcltech.com
Subject: Re: PR target/16482: first scheduling pass on SH4
From: Kaz Kojima <kkojima@rr.iij4u.or.jp>
In-Reply-To: <20041029.114328.127190349.kkojima@rr.iij4u.or.jp>
References: <20041015.195550.57454032.kkojima@rr.iij4u.or.jp>
	<orfz3y1g7p.fsf@livre.redhat.lsd.ic.unicamp.br>
	<20041029.114328.127190349.kkojima@rr.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-11/txt/msg00145.txt.bz2

> Alexandre Oliva <aoliva@redhat.com> wrote:
>>> 	* config/sh/sh.c (implicit_r0_use_block): New variable.
>>> 	(may_use_r0_in_reload, find_implicit_r0_use): New.
>>> 	(sh_md_init_global): Initialize and set implicit_r0_use_block.
>>> 	(sh_md_finish_global): Cleanup implicit_r0_use_block if needed.
>>> 	(implicit_r0_pressure): New.
>>> 	(sh_reorder): Use implicit_r0_pressure.
>>> 	(sh_reorder2): Likewise.
>>
>> I'm a bit concerned with this approach.  Consider, for example, a (mem
>> (reg)), in which reload finds this reg to be equivalent to a (plus
>> (reg) (reg)), or a (plus (reg) (const_int BIG)).  Both might end up
>> needing r0, and I don't quite see how you could prevent reload from
>> trying such a substitution.
> 
> Agreed.

BTW, I've seen many spill failures in compiling glibc with 4.0.0
for sh4 without -fno-schedule-insns.  Some of them can't be fixed
with my experimental patch.  For example,

(a)
strtod_l.c: In function 'round_and_return':
strtod_l.c:275: error: unable to find a register to spill in class 'R0_REGS'
strtod_l.c:275: error: this is the insn:
(insn:HI 39 32 34 2 strtod_l.c:198 (parallel [
            (set (reg:SF 64 fr0 [orig:160 D.8163 ] [160])
                (const_double:SF 0.0 [0x0.0p+0]))
            (use (reg/v:PSI 151 ))
            (clobber (scratch:SI))
        ]) 157 {movsf_ie} (nil)
    (expr_list:REG_UNUSED (scratch:SI)
        (nil)))

(b)
initgroups.c: In function 'initgroups':
initgroups.c:220: error: unable to find a register to spill in class 'R0_REGS'
initgroups.c:220: error: this is the insn:
(insn:HI 86 85 92 7 initgroups.c:214 (set (reg:SI 147 t)
        (eq:SI (reg/v:SI 10 r10 [orig:161 result ] [161])
            (const_int -1 [0xffffffffffffffff]))) 1 {cmpeqsi_t} (insn_list:REG_DEP_ANTI 81 (insn_list:REG_DEP_ANTI 82 (insn_list:REG_DEP_ANTI 83 (insn_list:REG_DEP_TRUE 84 (nil)))))
    (nil))

So your are quite right.  My approach wouldn't work at all for (b).
I hope that those failures also come from the lcm.c problem suggested
by Joern.

Regards,
	kaz