From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25128 invoked by alias); 11 Apr 2003 16:50:39 -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 25065 invoked from network); 11 Apr 2003 16:50:38 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 11 Apr 2003 16:50:38 -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 114854DE86; Fri, 11 Apr 2003 18:50:39 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Fri, 11 Apr 2003 18:50:40 +0200 Date: Fri, 11 Apr 2003 17:49:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030411165040.GA15771@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> <200304102200.35188.ebotcazou@libertysurf.fr> <20030410202612.GI9319@kam.mff.cuni.cz> <200304111356.23415.ebotcazou@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304111356.23415.ebotcazou@libertysurf.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00552.txt.bz2 > > The code is wrong for post-SUBREG_BYTE patch as it checks that the > > partial regs have exactly size of one word, but we do allow subregs on > > registers of different sizes. We need to verify that offset can > > represent the register exactly. > > Is it really wrong or is it incomplete now, in the post-SUBREG_BYTE era? Yes, it would force, for instance subregs of SFmode registers in 64bit sparc to be reloaded all the time (the original motivation for SUBREG_BYTE) > > > Looking as subreg_regno_offset, I think we need to practically check > > that division in: > > return (y_offset / (mode_multiple / nregs_multiple)) * nregs_ymode; > > Does not round. When it rounds we are having registers too wide and we > > must reload. > > All the other divisions should be safe from SUBREG definition that is > > already verified by my simplify_subreg code. > > We also should add a trap to subreg_regno_offset in the mainline... > > Seems to make sense? > > Do you mean that we can generate > > (subreg:HI (reg/v:SI 67) 2) > > and we currently have no means to fix it during the reload pass? Yes, we basically rely on the fact that we never generate them as we originaly generated everything on word basic. Honza > > -- > Eric Botcazou