From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1954 invoked by alias); 26 Jun 2011 20:03:36 -0000 Received: (qmail 1940 invoked by uid 22791); 26 Jun 2011 20:03:35 -0000 X-SWARE-Spam-Status: No, hits=-1.5 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; Sun, 26 Jun 2011 20:03:21 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTW7FYmNzknPXg== X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-059-021-240.pools.arcor-ip.net [84.59.21.240]) by post.strato.de (fruni mo41) (RZmta 25.18) with ESMTPA id i0651dn5QJCcX8 ; Sun, 26 Jun 2011 21:59:20 +0200 (MEST) Message-ID: <4E078F93.7060901@gjlay.de> Date: Sun, 26 Jun 2011 20:51:00 -0000 From: Georg-Johann Lay User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Denis Chertykov CC: Richard Henderson , 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> <4DF918A9.4070003@gjlay.de> <4DF92AEA.4000906@redhat.com> <4DF93B17.8020008@redhat.com> <4E03B658.8020509@redhat.com> In-Reply-To: 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/msg01947.txt.bz2 Denis Chertykov schrieb: > 2011/6/24 Richard Henderson : > >>On 06/23/2011 01:15 PM, Denis Chertykov wrote: >> >>>> text data bss dec hex filename >>>> 10032 25 0 10057 2749 bld-avr-orig/gcc/z.o >>>> 5816 25 0 5841 16d1 bld-avr-new/gcc/z.o >>> >>>Richard, can you send me this z.c file ? >>>Right now I'm notice that new code is worse. >> >>That's gcc.c-torture/compile/950612-1.c. > > I have founded that postreload optimizations can't handle results of > new L_R_A code. > I think that it's can be handled by CSE (postreload). > > This is a fragment from 950612-1.c: > > ---------- you can skip it I have a short version below ------- > (insn 5186 23 5187 2 (set (reg:HI 30 r30) > (const_int 128 [0x80])) c950612-1.c:20 9 {*movhi} > (nil)) > > (insn 5187 5186 5189 2 (set (reg:HI 30 r30) > (plus:HI (reg:HI 30 r30) > (reg/f:HI 28 r28))) c950612-1.c:20 21 {*addhi3} > (expr_list:REG_EQUIV (plus:HI (reg/f:HI 28 r28) > (const_int 128 [0x80])) > (nil))) > > (insn 5189 5187 2451 2 (set (mem/c:HI (plus:HI (reg:HI 30 r30) > (const_int 1 [0x1])) [8 %sfp+129 S2 A8]) > (reg:HI 18 r18)) c950612-1.c:20 9 {*movhi} > (nil)) > > (note 2451 5189 2537 2 NOTE_INSN_DELETED) > > (note 2537 2451 1651 2 NOTE_INSN_DELETED) > > (note 1651 2537 3180 2 NOTE_INSN_DELETED) > > (note 3180 1651 5191 2 NOTE_INSN_DELETED) > > (insn 5191 3180 5192 2 (set (reg:HI 30 r30) > (const_int 128 [0x80])) c950612-1.c:132 9 {*movhi} > (nil)) > > (insn 5192 5191 5071 2 (set (reg:HI 30 r30) > (plus:HI (reg:HI 30 r30) > (reg/f:HI 28 r28))) c950612-1.c:132 21 {*addhi3} > (expr_list:REG_EQUIV (plus:HI (reg/f:HI 28 r28) > (const_int 128 [0x80])) > (nil))) > > (insn 5071 5192 5073 2 (set (mem/c:HI (plus:HI (reg:HI 30 r30) > (const_int 3 [0x3])) [8 %sfp+131 S2 A8]) > (reg/v/f:HI 8 r8 [orig:211 pc ] [211])) c950612-1.c:132 9 {*movhi} > (nil)) > ------------------------------------------------------ > > Insns 5186,5187 equal to 5191,5192 and 5191,5192 can be removed, but > reload_cse_regs_1 operate only on one insn. > > 5186 Z=128 > 5187 Z=Y+128 ; REG_EQUIV Z=Y+128 > 5189 HI:[Z+1]=HI:R18 > ...(deleted insns) > 5191 Z=128 > 5192 Z=Y+128 ; REG_EQUIV Z=Y+128 > > (5191,5192) really a one three addressing add Z=Y+128. > Insns (5191,5192) exists because AVR havn't 3 addressing add. > Insn 5191 destroy REG_EQUIV (it's right), but reload_cse_regs_1 can't > optimize insns 5191,5192. Did you try to add constraint alternative to *addhi3? Like "*!d,d,n" or even "*!r,r,n" I saw some code improvement with that alternative. Johann > Right now I have only one idea: > 1. create peephole2 for joining such insns (5191,5192); > 2. inside machine dependent pass rerun postreload and may be gcse2; > 3. split joined insns to originals. > > Denis.