From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1093 invoked by alias); 14 Jun 2011 21:29:54 -0000 Received: (qmail 1080 invoked by uid 22791); 14 Jun 2011 21:29:52 -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; Tue, 14 Jun 2011 21:29:37 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTW7FYqNyUii X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-059-022-055.pools.arcor-ip.net [84.59.22.55]) by post.strato.de (fruni mo49) (RZmta 25.18) with ESMTPA id Y06835n5EKjlhv ; Tue, 14 Jun 2011 23:29:27 +0200 (MEST) Message-ID: <4DF7D2B5.1090708@gjlay.de> Date: Tue, 14 Jun 2011 21:38:00 -0000 From: Georg-Johann Lay User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Denis Chertykov CC: gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" , Richard Henderson 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> 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/msg01113.txt.bz2 Denis Chertykov schrieb: > 2011/6/14 Georg-Johann Lay : > >>Denis Chertykov schrieb: >> >>>2011/6/13 Georg-Johann Lay : >>> >>>>So you think is is pointless/discouraged to give a more realistic >>>>description of AVR addressing be means of MODE_CODE_BASE_REG_CLASS (instead >>>>of BASE_REG_CLASS) resp. REGNO_MODE_CODE_OK_FOR_BASE_P? >>>> >>>> >>>>>Look carefully at `out_movqi_r_mr'. >>>>>There are even two fake addressing modes: >>>>>1. [Y + infinite-dslacement]; >>>>>2. [X + (0...63)]. >>>> >>>>Yes, I know. The first is introduced by avr_legitimate_address_p and the >>>>second appears to be artifact of LEGITIMIZE_RELOAD_ADDRESS. >>>> >>>>The changes are basically MODE_CODE_BASE_REG_CLASS (introduced in 4.2) and a >>>>rewrite of avr_legitimate_address_p. The changes aim at a better addressing >>>>for X and to minimize fake addresses. >>>> >>>> >>>>>I have spent a many hours (days, months) to debug GCC (especially avr port >>>>>and reload) for right addressing modes. >>>>>I have stopped on this code. >>>>>AVR have a limited memory addressing and GCC can't handle it in native >>>>>form. >>>>>Because of that I have supported a fake adddressing modes. >>>> >>>>I assume the code is from prior to 4.2 when REGNO_MODE_CODE_OK_FOR_BASE_P >>>>and MODE_CODE_BASE_REG_CLASS had not been available so that supporting X >>>>required some hacking. >>>>All that would still be fine; however the new register allocator leads to >>>>code that noone would accept. Accessing a structure through a pointer is not >>>>uncommon, not even on AVR. So if Z is used for, say accessing flash, X >>>>appears to be the best register. >>>> >>>>The shortcoming in GCC is that there is no way to give costs of addressing >>>>(TARGET_ADDRESS_COST does different things). >>>> >>>>So take a look what avr-gcc compiles here: >>>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22242 >>>>I saw similar complains in forums on the web. >>>> >>>> >>>>>(Richard Henderson have a different opinion: GCC can, AVR port can't) >>>> >>>>What does he mean with that? >>>> >>>> >>>>>IMHO that three limited pointer registers is not enough for C compiler. >>>>>Even more with frame pointer it's only two and X is a very limited. >>>> >>>>The current implementation has several oddities like >>>> >>>>* allowing SUBREGs in avr-legitimate_address_p >>>>* changing BASE_REG_CLASS on the fly (by means of reload_completed) >>>> >>>>isn't that supposed to cause trouble? >>> >>>You can try to remove all oddities and check results. >>>Definitely something changed in GCC core since I wrote addressing code. >>> >>>Denis. >> >>For your interest, here is a patch that shows the changes in >>addressing mode. http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01029.html > Generally, the patch seems as a "right thing". I like it. > > How about a regression testing and code quality. > > Denis. 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 As I don't know how to fix a spill failure I stopped working on the patch. Perhaps it would help to have fake y+const addresses; I didn't try. As far as I remember, reload emits inefficient code in some situations when it tries to fit address into available addressing mode by adding constant. I could fix that by new constraint alternative in addhi3 insn, something like "=*!r,r,n". But that are just details. The major work left to be done are fixing spill fails and implementing appropriate LEGITIMIZE_RELOAD_ADDRESS which are beyond my skills. BTW, fixing PR48459, Richard ran immediately into a spill failure during newlib build: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459#c20 Johann