From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32164 invoked by alias); 9 Apr 2003 11:25: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 32157 invoked from network); 9 Apr 2003 11:25:43 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 9 Apr 2003 11:25:43 -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 AAFA74DECF; Wed, 9 Apr 2003 13:25:43 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Wed, 9 Apr 2003 13:25:44 +0200 Date: Wed, 09 Apr 2003 14:52:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030409112544.GA12755@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> <200304090804.30147.ebotcazou@libertysurf.fr> <20030409085743.GE9102@kam.mff.cuni.cz> <200304091105.24896.ebotcazou@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304091105.24896.ebotcazou@libertysurf.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00360.txt.bz2 > > What would prevent it from match on (subreg:DI (reg eax) 4)? > > GET_MODE_SIZE (GET_MODE (inner)) / UNITS_PER_WORD == 2 > HARD_REGNO_NREGS (REGNO (inner), GET_MODE (inner)) == 2 Hmm, I guess I see it finally :) Thanks for the patience. One problem is that reload is really dealing with the impossible subregs incorrectly. See simd-* testcases on gcc 3.2 compiled with SSE support - the (subreg:DF (XMM0:V3DF) 8) is produced, passed trought reload and then assembled as XMM0 as the registers are of size 16. I think we should at least abort when the SUBREG_BYTE is not represent via subreg_regno_offset. Will try to make patch for that in mainline. Concerning this testcase, the reload used to manage to get around this problem. It didn't get around intentionally and just because the instruction contrain does not accept SSE register so reload is needed anyway. The idea of reloading whole SSE register into integer is no-go as can be see from the other testcases. There are two cases when the reload is really needed: 1) we are not able to access the SUBREG_BYTE part because of the problem above because SUBREG_BYTE is not divisible by size of the register (there is no way to get the size of the register, but I guess we can use GET_MODE_SIZE / HARD_REGNO_NREGS) and we will also need to compensate the lowparts, This is the problem we are seeing. It is IMO questionable whether it is valid to see such scenario and whether local alloc can produce such a subregs that has no representation. My CANNOT_CHANGE_MODE_P patch avoids that as it causes the problem described above. 2) We are outputing into the register and the HARD_REGNO_NREGS is decreasing so we may convert subreg rewriting just part of the register to the subreg rewriting the lower part and clobbering upper part. This is what I beleive the conditional was originally invented for. Are we in the sync now? It seems to be that the conditional is still overconservative for 2) as it is still possible that the subreg is large enought to fit into HARD_REGNO_NREGS of the destination and it now ignores 1). It is question whether 1) can legaly happen at all but I see it does for 3.2 (and does not for 3.3). Honza > > > That was the original problem that made me to change the behaviour (we > > can't reload instructions needing two such subregged operands in -fPIC as > > we simply run out of registers) > > No, the problem was related to SSE regs. > > -- > Eric Botcazou