From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18233 invoked by alias); 13 Jun 2011 20:12:30 -0000 Received: (qmail 18224 invoked by uid 22791); 13 Jun 2011 20:12:28 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ey0-f175.google.com (HELO mail-ey0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jun 2011 20:12:14 +0000 Received: by eye27 with SMTP id 27so1959045eye.20 for ; Mon, 13 Jun 2011 13:12:13 -0700 (PDT) Received: by 10.14.1.71 with SMTP id 47mr2448161eec.128.1307995933147; Mon, 13 Jun 2011 13:12:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.186.16 with HTTP; Mon, 13 Jun 2011 13:11:53 -0700 (PDT) In-Reply-To: <4DF650B7.3030705@gjlay.de> References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> <4DF650B7.3030705@gjlay.de> From: Denis Chertykov Date: Mon, 13 Jun 2011 22:37:00 -0000 Message-ID: Subject: Re: [Patch, AVR]: Fix PR46779 To: Georg-Johann Lay Cc: gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" , Richard Henderson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/msg00997.txt.bz2 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 (inste= ad > 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) an= d a > rewrite of avr_legitimate_address_p. The changes aim at a better addressi= ng > for X and to minimize fake addresses. > >> I have spent a many hours (days, months) to debug GCC (especially avr po= rt >> 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: > =C2=A0http://gcc.gnu.org/bugzilla/attachment.cgi?id=3D22242 > 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. >>> >>> * "zero_extendqidi2" >>> * "zero_extendhidi2" >>> * "zero_extendsidi2" >>> >>> These are "orphan" insns: they deal with DI without having movdi >>> support so I removed them. >> >> This seems strange for me. > > As far as I know, to support a mode a respective mov insn is needed, which > is not the case for DI. I don't know the exact rationale behind that > (reloading?), just read is on gcc list by Ian Taylor (and also that it is > stronly discouraged to have more than one mov insn per mode). > > So if the requirement to have mov insn is dropped and without the burden = to > implement movdi, it would be rather easy to implement adddi3 and subdi3 f= or > avr... Personally, I don't like to maintain 64bits integers in AVR port, but may be somebody use it. Denis.