From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2333 invoked by alias); 13 Dec 2001 20:05:15 -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 1620 invoked from network); 13 Dec 2001 20:03:54 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 13 Dec 2001 20:03:54 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id VAA21996; Thu, 13 Dec 2001 21:03:49 +0100 Date: Thu, 13 Dec 2001 12:05:00 -0000 From: Jan Hubicka To: John David Anglin Cc: Jan Hubicka , gcc@gcc.gnu.org, rth@redhat.com Subject: Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880 Message-ID: <20011213210349.C21405@atrey.karlin.mff.cuni.cz> References: <20011213091433.F24699@atrey.karlin.mff.cuni.cz> <200112131947.fBDJlkci022193@hiauly1.hia.nrc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112131947.fBDJlkci022193@hiauly1.hia.nrc.ca> User-Agent: Mutt/1.3.20i X-SW-Source: 2001-12/txt/msg00717.txt.bz2 > > > I have come to the conclusion that there is a problem with > > > GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a > > > DCmode MEM with the above indexing) since the maximum number > > > of bytes that can be moved in a single insn is 8. > > Yes, this is the complex type hackery - basically it does the DC modes behind > > scene w/o validation from backend splitting it later. > > What you need is to figure out from where the subreg is comming and replace > > gen_SUBREG by simplify_gen_subreg. That should be enought I guess. > > > > In case simplify_gen_subreg for some purpose refuse to simplify memory in question, > > let me know. > > The subreg is coming from simplify_gen_subreg: > > new = simplify_subreg (outermode, op, innermode, byte); > if (new) > return new; > > if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode) > return NULL_RTX; > > return gen_rtx_SUBREG (outermode, op, byte); > } > > The call to simplify_subreg us not successful because mode_dependent_address_p > > returns true for: > > (plus:SI (mult:SI (reg:SI 21) > (const_int 16 [0x10])) > (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) > > At the moment, GO_IF_MODE_DEPENDENT_ADDRESS only accepts a plus with > a register and a constant address. I see. This is somewhat unfortunate. What I was thinking about is to add simplify_subreg_force wrapper that will do converison even if it looks wrong (resulting address is invalid or resulting register having not valid mode). This is usefull for few other places too (alter_subreg, split_di), perhaps it can be used here too. Sound sane? Honza > > Dave > -- > J. David Anglin dave.anglin@nrc.ca > National Research Council of Canada (613) 990-0752 (FAX: 952-6605)