From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7046 invoked by alias); 13 Apr 2003 12:12:23 -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 7037 invoked from network); 13 Apr 2003 12:12:22 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 13 Apr 2003 12:12:22 -0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id ACFE34DE86; Sun, 13 Apr 2003 14:12:22 +0200 (CEST) Date: Sun, 13 Apr 2003 20:04:00 -0000 From: Jan Hubicka To: Eric Botcazou Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Reload bug Message-ID: <20030413121222.GA24756@kam.mff.cuni.cz> References: <200304081937.16859.ebotcazou@libertysurf.fr> <200304121554.30377.ebotcazou@libertysurf.fr> <20030412142751.GD31150@kam.mff.cuni.cz> <200304130947.53856.ebotcazou@libertysurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304130947.53856.ebotcazou@libertysurf.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00613.txt.bz2 > > > The function appears to assume that reg XREGNO supports mode YMODE. Is > > > that by design? If so, I think you should mention it in the header > > > comment. > > > > Hmm, I am not certain what should happen there. We can either verify it > > here or the place we are doing so already... > > I think we should verify that the subreg is really representable. For low > parts, it's HARD_REGNO_MODE_OK (xregno, ymode) == 1. Are you sure that we > should not verify that HARD_REGNO_MODE_OK (xregno + offset, ymode) == 1 > at the very end of the function either, like in the original code? My original plan was to check only cases where subreg_regno_offset would reuslt in misscompilation. In the case HARD_REGNO_MODE_OK is false or CLASS_CANNOT_CHANGE_MODE is set, we would catch it elsewhere, but I agree that we can add it as incemental step. > > > > I think you should mention that the second "if" catches paradoxical > > > subregs too. > > > > Hmm, you are right. Then we can remove the first if too :) > > Even for big-endian platforms? I think the first "if" in the original code > catches paradoxical subregs on big-endian platforms and the second "if" > catches them on little-endian platforms. Paradoxical subreg has always 0 offset and the function to compute offset knows how to return 0 in this case so it will work. > > > No, I am actually trying to compute the size of the one ymode register > > in order to be able to compensate the lowpart operation. > > Imagine (subreg:QI (reg:DI) 3) is valid on little endian with > > nregs_ymode == 2 > > I presume you mean big-endian? And nregs_xmode == 2? > > Then wouldn't the following formula be better? > > offset -= subreg_lowpart_offset (mode_for_size (GET_MODE_SIZE (ymode) > / nregs_ymode, MODE_INT, 0), > mode_for_size (GET_MODE_SIZE (xmode) > / nregs_xmode, MODE_INT, 0)); > > It looks certainly more homogeneous than the former. This would result in same value as when the outer mode is bigger than word, it must be multiple of it and the original code would do paradoxical subreg and return 0, while this code would do subregs of equal sizes. Honza > > -- > Eric Botcazou