From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47991 invoked by alias); 6 Jan 2017 08:50:58 -0000 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 Received: (qmail 47976 invoked by uid 89); 6 Jan 2017 08:50:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*r:8.13.8 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jan 2017 08:50:56 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v068oqRX002067; Fri, 6 Jan 2017 02:50:52 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v068oqXu002066; Fri, 6 Jan 2017 02:50:52 -0600 Date: Fri, 06 Jan 2017 08:50:00 -0000 From: Segher Boessenkool To: Aurelien Buhrig Cc: gcc@gcc.gnu.org Subject: Re: input address reload issue Message-ID: <20170106085051.GI28613@gate.crashing.org> References: <094e7c3d-fc6c-1b0a-29c3-263cadec25a7@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <094e7c3d-fc6c-1b0a-29c3-263cadec25a7@gmail.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00028.txt.bz2 On Thu, Jan 05, 2017 at 05:18:46PM +0100, Aurelien Buhrig wrote: > The issue happens when reloading: > > (set (reg:QI 47 [ _9 ]) > (mem:QI (plus:SI (reg/v/f:SI 68 [orig:51 in ] [51]) > (const_int 1 [0x1]) > > My understanding is that IRA allocates hardregs to allocno which are > replaced by the reload pass which generates new reloads or spills regs > when needed, right? Yes. IRA chooses what hard registers to us where, or memory (i.e. no register) if that seems best (for example if it ran out of registers). Then afterwards reload / LRA fixes up everything that isn't valid. > Here the IRA chooses a reg (named r2)which makes the mem address not > legitimate. Is it valid to allocate a reg which makes non legitimate > address? reload will (or should ;-) ) fix it, but it would of course be better if IRA could make valid code immediately. > Assuming it is, my understanding is that the reload chooses a legitimate > reg (named a0 here) and shall emit insns (in emit_reload_insns) to set > a0 correctly (RELOAD_FOR_INPUT_ADDRESS). Right? > > So the insn: > (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1)) > > is transformed into: > (set (reg:SI 8 a0) (reg:SI 2 r2)) > (set (reg:SI 8 a0) (const_int 1)) > (set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0))) > (set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0)) That second instruction kills the result of the first, that is bad. It doesn't do anything useful in the first place. Maybe the first and the third instructions could be combined as well, or the third and the fourth, but I don't know your target. > This "basic" transformation requires two reload regs, but only one is > given/used/possible from the rl structure (in emit_reload_insns). > > So where does the issue comes from? The need for 2 reload regs, the > transformation which is too "basic" and could be optimized to use only > one reload reg, or any wrong/missing reload target hook? Look at the dump file for reload to see where things come from. Also everything Jeff said; you really want LRA. Segher