From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8186 invoked by alias); 21 Mar 2012 14:03:04 -0000 Received: (qmail 8129 invoked by uid 22791); 21 Mar 2012 14:03:00 -0000 X-SWARE-Spam-Status: No, hits=-1.6 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, 21 Mar 2012 14:02:46 +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 smtp.strato.de (klopstock mo10) (RZmta 28.2 AUTH) with ESMTPA id 906d17o2LDLsWl ; Wed, 21 Mar 2012 15:02:42 +0100 (MET) Message-ID: <4F69DF82.2020200@gjlay.de> Date: Wed, 21 Mar 2012 14:03:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: Steven Bosscher CC: gcc-patches@gcc.gnu.org, Denis Chertykov , Eric Weddington Subject: Re: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take #2 References: <4F5A4FFE.9000203@gjlay.de> <4F68E062.5040202@gjlay.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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: 2012-03/txt/msg01433.txt.bz2 Steven Bosscher wrote: > On Tue, Mar 20, 2012 at 8:54 PM, Georg-Johann Lay wrote: >> Dropping the first patch which does not work because at expand-time there >> must not be pre-/post-modify addressing :-( > > Have you tried to fix that, instead? Or at least ask around a bit to > see what people would think about that idea? The reasons why things > are the way they are, may not be applicable anymore. No, I didn't try to fix it. I am not experienced enough in that field. Moreover, at least as far as avr is concerned, using post-inc would just be a hack, too. > For example, perhaps the only reason for not having pre-/post-modify > addressing modes earlier is that the old "flow" dataflow frame work > didn't handle them. And it doesn't seem to be so black-and-white: The > very pass you ran into problems with first, cprop, does handle > pre-/post-modify addresses in local cprop. Some other passes simply > take the conservative path and drop pre-/post-modify (like CSE, which The problems were not only in cprop but also in cselib. > doesn't record values from them). It may be a relatively small job to > make everything accept them, and you may be something that's also > helpful for other targets. > > Ciao! > Steven