From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25223 invoked by alias); 8 Apr 2003 22:41:44 -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 25215 invoked from network); 8 Apr 2003 22:41:41 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 8 Apr 2003 22:41:41 -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 983AC4DECF; Wed, 9 Apr 2003 00:41:41 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Wed, 9 Apr 2003 00:41:44 +0200 Date: Wed, 09 Apr 2003 00:44:00 -0000 From: Jan Hubicka To: Jan Hubicka , rth@redhat.com Cc: Eric Botcazou , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030408224144.GF13052@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> <20030408212528.GC11492@kam.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030408212528.GC11492@kam.mff.cuni.cz> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00339.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 Actually I think the problem is just that the patch has never get into 3.2 line. The patch is pretty involved: * combine.c (simplify_set): Reverse order of ragumetns to REG_CANNOT_CHANGE_MODE_P * df.c (df_def_record_1): Likewise. * recog.c (register_operand): Likewise. * simplify-rtx.c (simplify_subreg): Likewise. * hard-reg-set.h (REG_CANNOT_CHANGE_MODE_P): Update use of CANNOT_CHANGE_MODE_CLASS. * regclass.c (cannot_change_mode_set_regs, invalid_mode_change_p): Likewise. * reload.c (push_reload): Likewise. * alpha.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * ia64.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * mips.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * mips-protos.h (mips_cannot_change_mode_class): Update prototype. * mips.c (mips_cannot_change_mode_class): Update. * pa64-regs.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * rs6000.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * s390.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * sh.h (CANNOT_CHANGE_MODE_CLASS): Update definition. * sh-protos.h (sh_cannot_change_mode_class): Update prototype. * sh.c (sh_cannot_change_mode_class): Update. * i386.h (CANNOT_CHANGE_MODE_CLASS): New. * tm.texi (CANNOT_CHANGE_MODE_CLASS): Update documentation. and I believe that the MMX suport in 3.2 is in so bad shape that I would simply close the bugreport claiming that 3.3 fixes that. Honza