From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27138 invoked by alias); 30 Jul 2009 14:32:16 -0000 Received: (qmail 27125 invoked by uid 22791); 30 Jul 2009 14:32:15 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Jul 2009 14:32:09 +0000 Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c60.cesmail.net with ESMTP; 30 Jul 2009 10:32:06 -0400 Received: from 83-244-211-66.cust-83.exponential-e.net (83-244-211-66.cust-83.exponential-e.net [83.244.211.66]) by webmail.spamcop.net (Horde MIME library) with HTTP; Thu, 30 Jul 2009 10:32:07 -0400 Message-ID: <20090730103207.rj014844ou8o0cok-nzlynne@webmail.spamcop.net> Date: Thu, 30 Jul 2009 14:32:00 -0000 From: Joern Rennecke To: Andrew Stubbs Cc: Ian Lance Taylor , gcc@gcc.gnu.org Subject: Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) 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/msg00619.txt.bz2 > This is then transformed by subst_reloads to the final broken form: > > (insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9) > (plus:SI (reg:SI 8 r8) > (reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil)) > > This is logically correct as r9 genuinely does contain the result of the > substituted expression, but it does not satisfy the constraints. > > And here's where I get stuck. I don't know where in the code it's > supposed to check that the code will be correct after the substitution. > > The (plus (plus ...) ...) rtl is generated by > find_reloads_subreg_address using make_memloc and plus_constant, and it > seems correct in itself. This used to be 'handled' by reload register allocation which would use the same reload register for RELOAD_FOR_INPUT_ADDRESS as for RELOAD_FOR_INPADDR_ADDREESS if both are for the same operand. It is strange that you have two RELOAD_FOR_INPUT_ADDRESS reloads instead. Although, in terms of ensuring correctness, it would be saner if gen_reload would make sure it generates valid code even for unusual reload register allocations. Unfortunately, that'll require it to make a guess if a two-address add is required; you can scan the insn pattern for matching constraints, but that is somewhat hit-and-miss (obviously you can't use constrain_operands there unless you want to save / restore all the extraction data); you'll end up generating some unneeded register-register moves on some architectures. But you could make sure they get removed in postreload.