From patchwork Mon Jan 30 19:28:44 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 138625 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 7E9A1B6EEA for ; Tue, 31 Jan 2012 06:29:05 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1328556546; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=ZRmhQWoPsnuwsittWcRC HJmHEKY=; b=Nzd9xBiMx5eJ0B9VGuzEFZZDkjh2ARIweApFZ5oxGMVJuyGYGBNo VVldXWVWMfppjdqIivqsyTGikEkZRKdyp9dRuFNve6CP0+m5YKEvQk4utYUR9Hms DNMCYSlKpnsfFppSi4UpntT2sSB+a70pu0o8TZM4YMC/xZcB+u00Mss= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Mail-Followup-To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ofoN6EXXJvyuUYVUqQDQZDqzRX0F/fhHH0oH5+xzjPs24pAtDD4MXWpgYdmSL2 acxuZiqfTNqecrIG5JrgHslXBRynmxxsNhluxAa1OwQFGK13BNlhoyNRWIqoAaIF uSjMqM7Z4X6S0ihx/e3c/A2nN0DcjKa2yqCB//3ElFCKY=; Received: (qmail 8382 invoked by alias); 30 Jan 2012 19:29:02 -0000 Received: (qmail 8373 invoked by uid 22791); 30 Jan 2012 19:29:02 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com) (209.85.212.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jan 2012 19:28:48 +0000 Received: by wibhq7 with SMTP id hq7so4045534wib.20 for ; Mon, 30 Jan 2012 11:28:47 -0800 (PST) Received: by 10.180.81.66 with SMTP id y2mr29432886wix.20.1327951727499; Mon, 30 Jan 2012 11:28:47 -0800 (PST) Received: from localhost (rsandifo.gotadsl.co.uk. [82.133.89.107]) by mx.google.com with ESMTPS id bj10sm32346917wib.9.2012.01.30.11.28.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 11:28:46 -0800 (PST) From: Richard Sandiford To: Eric Botcazou Mail-Followup-To: Eric Botcazou , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org Subject: Re: Fix multi-reg regno_reg_rtx entry References: <871uqkjcbs.fsf@firetop.home> <201201291717.19526.ebotcazou@adacore.com> <878vkq8fvz.fsf@firetop.home> <201201292209.08906.ebotcazou@adacore.com> Date: Mon, 30 Jan 2012 19:28:44 +0000 In-Reply-To: <201201292209.08906.ebotcazou@adacore.com> (Eric Botcazou's message of "Sun, 29 Jan 2012 22:09:08 +0100") Message-ID: <8739axhtw3.fsf@firetop.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Eric Botcazou writes: > I'm not sure about the assertion though: if it happens to trigger, the > fix will probably entail far-reaching changes in the back-end, so it's > probably safer to delay it until the next stage #1. Yeah, that's probably true. How does this version look? Thanks, Richard gcc/ * function.h (regno_reg_rtx): Adjust comment. * reginfo.c (init_reg_modes_target): Only use the previous mode if it fits within one register. Remove MIPS comment. Index: gcc/function.h =================================================================== --- gcc/function.h 2012-01-30 19:23:22.000000000 +0000 +++ gcc/function.h 2012-01-30 19:23:51.000000000 +0000 @@ -87,10 +87,13 @@ struct GTY(()) emit_status { }; -/* Indexed by pseudo register number, gives the rtx for that pseudo. - Allocated in parallel with regno_pointer_align. - FIXME: We could put it into emit_status struct, but gengtype is not able to deal - with length attribute nested in top level structures. */ +/* Indexed by register number, gives an rtx for that register (and only + that register). For pseudo registers, it is the unique rtx for + that pseudo. For hard registers, it is an rtx of the mode specified + by reg_raw_mode. + + FIXME: We could put it into emit_status struct, but gengtype is not + able to deal with length attribute nested in top level structures. */ extern GTY ((length ("crtl->emit.x_reg_rtx_no"))) rtx * regno_reg_rtx; Index: gcc/reginfo.c =================================================================== --- gcc/reginfo.c 2012-01-30 19:01:55.000000000 +0000 +++ gcc/reginfo.c 2012-01-30 19:25:01.000000000 +0000 @@ -615,13 +615,15 @@ init_reg_modes_target (void) { reg_raw_mode[i] = choose_hard_reg_mode (i, 1, false); - /* If we couldn't find a valid mode, just use the previous mode. - ??? One situation in which we need to do this is on the mips where - HARD_REGNO_NREGS (fpreg, [SD]Fmode) returns 2. Ideally we'd like - to use DF mode for the even registers and VOIDmode for the odd - (for the cpu models where the odd ones are inaccessible). */ + /* If we couldn't find a valid mode, just use the previous mode + if it is suitable, otherwise fall back on word_mode. */ if (reg_raw_mode[i] == VOIDmode) - reg_raw_mode[i] = i == 0 ? word_mode : reg_raw_mode[i-1]; + { + if (i > 0 && hard_regno_nregs[i][reg_raw_mode[i - 1]] == 1) + reg_raw_mode[i] = reg_raw_mode[i - 1]; + else + reg_raw_mode[i] = word_mode; + } } }