From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22218 invoked by alias); 10 Jun 2011 10:14:07 -0000 Received: (qmail 22207 invoked by uid 22791); 10 Jun 2011 10:14:06 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Jun 2011 10:13:53 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGObUOFkj18odoYNahU4Q== X-RZG-CLASS-ID: mo00 Received: from [192.168.0.22] (business-188-111-022-002.static.arcor-ip.net [188.111.22.2]) by post.strato.de (jimi mo63) (RZmta 25.18) with ESMTPA id 2020a0n5A8Irbf ; Fri, 10 Jun 2011 12:09:58 +0200 (MEST) Message-ID: <4DF1ED76.4030507@gjlay.de> Date: Fri, 10 Jun 2011 10:23:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: Denis Chertykov CC: 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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/msg00819.txt.bz2 Denis Chertykov schrieb: > 2011/6/9 Georg-Johann Lay : >> Denis Chertykov schrieb: >>> 2011/6/9 Georg-Johann Lay : >> I agree with you. However, I think that the risk of spill failure >> should be minimized. I have no idea how to fix a splill failure like >> the following that occurs in testsuite (with -Os, no matter if the >> patch is applied or not): >> >> ./gcc/testsuite/gcc.c-torture/execute/pr38051.c:189:1: error: unable >> to find a register to spill in class 'POINTER_REGS' >> ./gcc/testsuite/gcc.c-torture/execute/pr38051.c:189:1: error: this is >> the insn: >> (insn 61 60 62 10 (set (reg/v:SI 12 r12 [orig:73 b0 ] [73]) >> (mem:SI (subreg:HI (reg/v:SI 70 [ srcp2 ]) 0) [2 *D.2218_56+0 >> S4 A8])) ./gcc/testsuite/gcc.c-torture/execute/pr38051.c:64 12 {*movsi} >> (nil)) >> ./gcc/testsuite/gcc.c-torture/execute/pr38051.c:189:1: internal >> compiler error: in spill_failure, at reload1.c:2113 >> >> Actually I have no idea if the snip in avr_hard_regno_mode_ok actually >> would reduce the risk of spill failure :-/ > > I think, no. > I will try to debug reload for pr38051.c (It will be a long process 1-2 weeks) > > Denis. Thanks for doing that! Debugging reload is really no fun... I see spill fails for these test cases with -mmcu=atmega128 * gcc.c-torture/execute/pr38051.c (-Os) * gcc.dg/pr43670.c (-O -ftree-vrp -fcompare-debug) * gcc.dg/20030324-1.c (-O -fstrict-aliasing -fgcse) all complainins contain RTX like (mem:SI/SF (subreg:HI (reg:SI xxx) 0/2)) Then I have a question on spill failures: There is PR46278, an optimization flaw that goes as follows: The avr BE defines fake addressing mode X+const that has to be written down in asm as X += const a = *X X -= const The comment says that this is just to cover a corner case, however the new register allocator uses this case more often or even greedily. There is no way to describe the cost for such an access, and as X has lower prologue/epilogue cost than Y, X is preferred over Y often. In 4.7, I see that flaw less often than in 4.5. However, I think the best way is not to lie at the register allocator and not to supply a fake instruction like that. So I started to work on a fix. The changes in avr.h are: * config/avr/avr.h (BASE_REG_CLASS): Remove. (REG_OK_FOR_BASE_NOSTRICT_P): Remove. (REG_OK_FOR_BASE_STRICT_P): Remove. (MODE_CODE_BASE_REG_CLASS): New Define. (REGNO_MODE_CODE_OK_FOR_BASE_P): New Define. The macros REGNO_MODE_CODE_OK_FOR_BASE_P and MODE_CODE_BASE_REG_CLASS allow a better, fine grained control over addressing modes for each hard register and allow to support X without fake instructions. The code quality actually improves, but I see a new spill failure for the test case * gcc.c-torture/compile/950612-1.c On the one hand, that test case has heavy long long use and is no "real world code" to run on AVR. On the other hand, I don't think trading code quality here against ICE there is a good idea. What do you think about that? As I have no idea how to fix a spill failure in the backend, I stopped working on a patch. Then I observed trouble with DI patterns during libgcc build and had to remove * "zero_extendqidi2" * "zero_extendhidi2" * "zero_extendsidi2" These are "orphan" insns: they deal with DI without having movdi support so I removed them. Johann