From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8213 invoked by alias); 10 Apr 2003 20:26:09 -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 8201 invoked from network); 10 Apr 2003 20:26:09 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 10 Apr 2003 20:26:09 -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 532E54DE86; Thu, 10 Apr 2003 22:26:10 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Thu, 10 Apr 2003 22:26:12 +0200 Date: Thu, 10 Apr 2003 20:43:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030410202612.GI9319@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> <20030409112544.GA12755@kam.mff.cuni.cz> <200304101201.50800.ebotcazou@libertysurf.fr> <200304102200.35188.ebotcazou@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304102200.35188.ebotcazou@libertysurf.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00451.txt.bz2 > > I think you're completely right: the reload pass has no specific > > infrastructure for dealing with invalid subregs. It may "fix" these > > subregs, but only if it happens that the operand needs reloading because > > of the insn constraints. > > I've found why: the code has been disabled in find_reloads() > > /* This following hunk of code should no longer be > needed at all with SUBREG_BYTE. If you need this > code back, please explain to me why so I can > fix the real problem. -DaveM */ > #if 0 > /* Subreg of a hard reg which can't handle the subreg's mode > or which would handle that mode in the wrong number of > registers for subregging to work. */ > || (GET_CODE (operand) == REG > && REGNO (operand) < FIRST_PSEUDO_REGISTER > && ((GET_MODE_SIZE (operand_mode[i]) <= UNITS_PER_WORD > && (GET_MODE_SIZE (GET_MODE (operand)) > > UNITS_PER_WORD) > && ((GET_MODE_SIZE (GET_MODE (operand)) > / UNITS_PER_WORD) > != HARD_REGNO_NREGS (REGNO (operand), > GET_MODE (operand)))) > || ! HARD_REGNO_MODE_OK (REGNO (operand) + offset, > operand_mode[i]))) > #endif > > Re-enabling it fix PR target/10286. > > Now the question: what is the replacement machinery that is supposed to be > doing the work? Hmm, I've wondered about this piece of code as well today in the train. I think Davej was wrong to disable it without approripate replacement. 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. 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? Honza