From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32092 invoked by alias); 28 Jan 2002 21:47:33 -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 31975 invoked from network); 28 Jan 2002 21:47:28 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 28 Jan 2002 21:47:28 -0000 Received: from rtl.cygnus.com (rtl.sfbay.redhat.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA28240; Mon, 28 Jan 2002 13:47:27 -0800 (PST) From: Jim Wilson Received: (wilson@localhost) by rtl.cygnus.com (8.6.12/8.6.4) id NAA19688; Mon, 28 Jan 2002 13:47:26 -0800 Date: Mon, 28 Jan 2002 15:41:00 -0000 Message-Id: <200201282147.NAA19688@rtl.cygnus.com> To: law@redhat.com Subject: Re: paradoxical subreg problem In-Reply-To: <16350.1012242676@porcupine.cygnus.com> Organization: Cygnus Solutions, CA Cc: gcc@gcc.gnu.org X-SW-Source: 2002-01/txt/msg01838.txt.bz2 In article <16350.1012242676@porcupine.cygnus.com> you write: >Think very very carefully about the semantics of a paradoxical subreg. A paradoxical subreg can have one of two different meanings, depending on context. 1) The extra bits are don't care bits. This usage can occur anywhere, and is primarily used when manipulating values larger than the word size. This perhaps requires that the operand be a register, but I'm not sure. For instance, on a 32-bit target, given (subreg:DI (reg:SI 100)), the extra 32-bits are don't care bits. 2) The extra bits are known to be zero or one, depending on whether loads zero or sign extend by default. This is only used for values smaller than or equal to the the word size, and I think this also requires that the operand be a MEM, but I'm not positive about the last condition. For instance, on a 32-bit target with zero-extending loads, given (subreg:SI (mem:QI ...)), the extra 24-bits are known to be zero. This usage occurs only between combine and reload. It has been this way for over a decade I'd say. The first meaning came first, and has obvious uses. I believe the second meaning arose because of our primarily CISC oriented view at the time. Since predicates know about subregs already, using subregs for zero/sign extended loads means that they would be accepted automatically. If we added the explicit zero/sign extension operators, then a lot of predicates and patterns would have to be modified to allow zero/sign extension operators. Nowadays, the prevailing wisdom is that you should never create an insn that will require a reload, and thus it may be that the second type of paradoxical subreg is no longer useful. We already have the problem that combine.c and recog.c have special code checking INSN_SCHEDULING to get rid of the second class of paradoxical subregs. This code is unclean though, as we never should have created these paradoxical subregs on a load/store (RISC) machine to begin with. If the patterns in the md file don't allow MEM, then recog should not be accepting (subreg (mem)) as a register operand. There might be a second justification that this feature allows for better optimization, by exposing zero/sign extensions that would otherwise be hidden. However, I don't think this is convincing. Combine has code to keep track of sign-bit copies now, and we can do this just as well by using explicit zero_extend/sign_extend operators instead of using subregs. Jim