From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37767 invoked by alias); 20 Aug 2019 07:30:01 -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 37752 invoked by uid 89); 20 Aug 2019 07:30:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=sit, johndarringtonwattleidau, H*i:sk:2019082, H*f:sk:2019082 X-HELO: mail-lj1-f196.google.com Received: from mail-lj1-f196.google.com (HELO mail-lj1-f196.google.com) (209.85.208.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Aug 2019 07:29:59 +0000 Received: by mail-lj1-f196.google.com with SMTP id z17so4158195ljz.0 for ; Tue, 20 Aug 2019 00:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0f5uhhH/rJlXWjT1iB9znIs4dWBa8bBv/JMz9CCr8rU=; b=S0strzZmcbBdsUVpZTFdYB8+k+b4kZniZ/2F8fEjOiRS16XyJLv9mJ4HCI7tP05mIB JZze3sKbhLAV3icutPAZv7MY1pOPzRry1KYoCLtGwNyN5V8Ou37FlihXN2XgO0rv4cZC biZpBE/L7Mj/JrSOvLmKxOp+eo7yG8PnktcVNfTvIewj0ZqaluwqmyUCAkcUH2ja/z0z LmBJOWpUiBh6oOdiPBjtr0b1W1O3bd8IFVI8x5T6ubkXAIt+lzX5EwhRcJSCmPI7HoSr tTkbMim4+3VwL01SM9c88pWp2R4sJTkb6DOwZX6+LFTL1D7H8cujGhtlBAZ/RsrwYjxD LhIg== MIME-Version: 1.0 References: <20190815173559.kbp3uja7jklx74iy@jocasta.intra> <3c6c87ce-a38f-728d-e083-aa066d531790@redhat.com> <20190816112357.ep7fns6skm5emoey@jocasta.intra> <5693be1f-4351-94ab-9096-f6e4f9f875c1@redhat.com> <20190819073553.pi644qzyokxmynr2@jocasta.intra> <16f173b7-d835-48f9-aaed-d5d38d4748ca@redhat.com> <20190819150711.GL31406@gate.crashing.org> <20190819180644.wn7s2dxdgjlwvdw7@jocasta.intra> <20190820070729.efox77kw3jhovswh@jocasta.intra> In-Reply-To: <20190820070729.efox77kw3jhovswh@jocasta.intra> From: Richard Biener Date: Tue, 20 Aug 2019 07:30:00 -0000 Message-ID: Subject: Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra] To: John Darrington Cc: Segher Boessenkool , Vladimir Makarov , GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00152.txt.bz2 On Tue, Aug 20, 2019 at 9:07 AM John Darrington wrote: > > On Tue, Aug 20, 2019 at 08:56:39AM +0200, Richard Biener wrote: > > > Most of these suggestions involve adding some sort of virtual registers > > So I hacked the machine description to add two new registers Z1 and Z2 > > with the same mode as X and Y. > > > > Obviously the assembler balks at this. However the compiler still > > ICEs at the same place as before. > > > > So this suggests that our original diagnosis, viz: there are not enough > > address registers was not accurate, and in fact there is some other > > problem? > > That sounds likely. Given you have indirect addressing you could > simulate N virtual regs by placing them in a virtual reg table in memory > and accessed via a fixed address register (assuming all instructions > that would need an address reg also can take that indirect from memory). > > That was my plan. Accordingly, extending the md to provide N additional > regs (N currently = 2) was the first step. Having doubled the number > of available address registers, I had expected this would fix most of the > ICEs (but cause a lot of assembler errors). > > However it hasn't eliminated any ICEs. lra is still complaining > "unable to find a register to spill" So the plan seems to have fallen > over at the first hurdle. Why can it still not spill registers despite > having a lot more of them? You really have to sit down and trace the LRA code with a debugger to tell... unfortunately the dumps aren't verbose enough to tell. Usually after spilling the insn constraints can still not be satisfied, the main question is usually why. Richard. > J'