From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23537 invoked by alias); 8 Apr 2003 21:25:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23506 invoked from network); 8 Apr 2003 21:25:26 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 8 Apr 2003 21:25:26 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 379784DECF; Tue, 8 Apr 2003 23:25:26 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Tue, 8 Apr 2003 23:25:28 +0200 Date: Tue, 08 Apr 2003 23:16:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030408212528.GC11492@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304081937.16859.ebotcazou@libertysurf.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00336.txt.bz2 > Hello Jan, > > I've narrowed down the bug reported as PR optimization/10233, a regression > from GCC 3.2 present on the 3.2 branch since 3.2.1 (but latent on all active > branches), to this patch > > Thu Oct 17 17:14:07 CEST 2002 Jan Hubicka > > PR opt/7630 > * reload.c (reload_inner_reg_of_subreg): New argument output; > (push_reload): Update call. > > > We are trying to reload > > (subreg:SI (reg/v:DI 29 rmm0 [68]) 4) > > as the 'in' argument of push_reload. > > Before your patch, the compiler correctly detected that the whole register > needs to be reloaded because we can't access the high part of MMX regs. How it did detected that? I believe it is just pessimization masking a bug as currently there is no way how to realize that subreg:SI of MMX with offset 4 register is not valid (and with offset 0 is). Thinking about it again, I think we can rely on HARD_REGNO_NREGS and compute how large the inidividular registers really are, but I don't think this is used anywhere in the code. It should not get recognized earlier than in reload as we should not allocate value with subreg undoable in MMX register into MMX register (unless rest of insns dictates otherwise). We've chatted about this with Richard > > But now reload_inner_reg_of_subreg returns 0 for this subreg because its > return value depends upon the context: if we pass it an 'in' argument, it > will not check the following condition > > /* If the outer part is a word or smaller, INNER larger than a > word and the number of regs for INNER is not the same as the > number of words in INNER, then INNER will need reloading. */ > > which happens to apply to this subreg. > > Then the subsequent logic is fooled and we end up reloading > > (reg/v:SI 29 emm0) > > > The rationale for the patch is there: > http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00628.html > > The last sentence: "However it is completely irrelevant for input operand in > all cases - we always can move just the small part of register and use it > directly, so I've added new operand to bypass this logic in the input > operand case." > > Did you intend to disable the condition for low parts only? (there appears to No, it is valid for high parts too as long as the register is possible (imagine the xmm being replaced by eax). I think we can add extra test realizing how large the registers are when index is nonzero. This will get bit tricky to get right when indexes are nonzero for lowparts. Richard? Honza > be no testcase associated with the patch so it's hard to tell). If so, does > the following patch fit your needs? > > -- > Eric Botcazou > > > * reload.c (reload_inner_reg_of_subreg): Require reloading for > non-low parts of input operands.