This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR target/16482: first scheduling pass on SH4
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Cc: tm_gccmail at kloo dot net, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, joern dot rennecke at st dot com, naveens at noida dot hcltech dot com
- Date: 28 Oct 2004 22:11:06 -0300
- Subject: Re: PR target/16482: first scheduling pass on SH4
- Organization: Red Hat Global Engineering Services Compiler Team
- References: <Pine.LNX.4.21.0410142001220.26875-100000@mail.kloo.net><20041015.195550.57454032.kkojima@rr.iij4u.or.jp>
On Oct 15, 2004, Kaz Kojima <kkojima@rr.iij4u.or.jp> 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.
That said, your patch definitely fixes a real problem. I'm just
concerned that it doesn't fix it completely. The approach feels a bit
like overkill, but I could live with it. JÃrn, any concerns? Anyone,
any further thoughts?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}