From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22086 invoked by alias); 16 May 2011 15:36:59 -0000 Received: (qmail 21980 invoked by uid 22791); 16 May 2011 15:36:57 -0000 X-SWARE-Spam-Status: No, hits=-1.7 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; Mon, 16 May 2011 15:36:43 +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 (klopstock mo5) (RZmta 25.18) with ESMTPA id Y05b73n4GEq4X8 ; Mon, 16 May 2011 17:36:27 +0200 (MEST) Message-ID: <4DD1447B.9060008@gjlay.de> Date: Mon, 16 May 2011 17:40: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 Weddington Subject: Re: [Patch,AVR]: Fix PR27663 References: <4DBEC003.4050300@gjlay.de> <4DCAD237.3010008@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-05/txt/msg01146.txt.bz2 Denis Chertykov schrieb: > 2011/5/11 Georg-Johann Lay : >> Denis Chertykov schrieb: >>> 2011/5/2 Georg-Johann Lay : >>> >>>> This is a fix for an optimization flaw when a long value is composed >>>> from byte values. >>>> >>>> For -fsplit-wide-types (which is still default for avr) the code is >>>> worse than with -fno-split-wide-types. The code for the test case is >>>> better in either situations, i.e. compared to code without the patch, >>>> but it is still not optimal. >>>> >>>> Fixing this by some combine patterns is the only thing the BE can do. >>>> I did not write more complex patterns because things get too complex >>>> with little performance gain. >>>> >>>> Tested without regressions. >>>> >>>> Johann >>>> >>>> 2011-05-02 Georg-Johann Lay >>>> >>>> PR target/27663 >>>> * config/avr/predicates.md (const_8_16_24_operand): New predicate. >>>> * config/avr/avr.md ("*iorqi.byte0", >>>> "*iorqi.byte1-3"): New define_insn_and_split patterns. >>>> >>> I'm sorry, but I dot'n like to have a both combiner related patches in >>> port because code improvement isn't much and your patterns are >>> difficult to understand and maintain. >>> >>> May be somebody else have a different oppinion ? >>> I'm open to discussion. >>> >>> Denis. >> Let me add that the patch is generic enough to also improve ORing HI against >> QI like described in >> >> http://gcc.gnu.org/PR41076 >> >> which is not uncommon on avr. > > You right here. > Please, apply the patch. Applied the current version of the patch: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173792 There are still situations that could be handled easily by avr like: [1]: Two instructions (set (reg:HI 50) (ior:HI (ashift:HI (zero_extend:HI (reg:QI 52)) (const_int 8)) (zero_extend:HI (reg:QI 55)))) [2]: Two instructions (set (reg:HI 50) (ior:HI (ashift:HI (reg:HI 51) (const_int)) (zero_extend:HI (reg:QI 55)))) [3]: One Instruction (set (reg:HI 50) (ior:HI (ashift:HI (reg:HI 51) (const_int 8)) (reg:HI 54))) If you agree, I make a patch to cover these cases, too. Just for HI, without mode iterators so that they are easier to understand. IMO it's preferred to do some pre-reload transforms instead of trying to catch such situations in peepholes or let the optimization opportunity pass by without making use of it. Unfortunately, there is no standard form the middle end tries; it differs depending on if a value is in memory or in a register and of -fsplit-wide-types is on or not. The patterns may seem complicated, but it's just what's going on... Johann > > Denis. >