From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30741 invoked by alias); 15 Jun 2011 20:40:32 -0000 Received: (qmail 30733 invoked by uid 22791); 15 Jun 2011 20:40:32 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Jun 2011 20:40:18 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTS5oCG7h41Ong== X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-058-226-031.pools.arcor-ip.net [84.58.226.31]) by post.strato.de (cohen mo12) (RZmta 25.18) with ESMTPA id N007fdn5FKSv2W ; Wed, 15 Jun 2011 22:40:11 +0200 (MEST) Message-ID: <4DF918A9.4070003@gjlay.de> Date: Wed, 15 Jun 2011 21:58:00 -0000 From: Georg-Johann Lay User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Richard Henderson CC: Denis Chertykov , gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" Subject: Re: [Patch, AVR]: Fix PR46779 References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> <4DF650B7.3030705@gjlay.de> <4DF73490.2080709@gjlay.de> <4DF7D2B5.1090708@gjlay.de> <4DF8ED42.1030706@redhat.com> In-Reply-To: <4DF8ED42.1030706@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01181.txt.bz2 Richard Henderson schrieb: > On 06/14/2011 02:29 PM, Georg-Johann Lay wrote: > >>I tested on some handcrafted examples and on the code attached to >>PR46278. The generated code looked very good and so I started >>regression testing but found at spill fail in >> gcc.c-torture/compile/950612-1.c > > I reproduced this today. > > The Problem is that we really have run out of registers. X and Z > are both in use, and we're attempting to spill them for caller-save. > There is no register in which to load fp+158 so that we can save > either X or Z. Thanks for the analysis, that makes thinks clearer. But I still wonder what's the very problem. Any architecture has limited reg+const addressing and limited number of address registers. I definetely saw architectures run out of registers and reload manages to access stack beyond reg+maxoff without any hacks and clear and straight forward backend. Bigger machines definetely have bigger maxoff and more address regs, but the software that's intended to run on them is considerably more complicated. Yet gcc doesn't run into problems and reload can cope with that. > You're going to have to have some support for fp+large somewhere. So there must be something fundamentally different between avr and other ports? Is there a minimum requirement for add3 insn like "r,r,n" alternative so that it can add a const without reload? Johann > r~