From patchwork Mon Feb 20 21:10:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 142192 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 76CFBB6EF3 for ; Tue, 21 Feb 2012 08:11:29 +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=1330377091; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=9WR9cZz 9H1oMoKmMHmm1L8gNMX0=; b=EklQoPzViBCXKrHj/thahJBETiMXzFhCv3GMqfL W11iDKIiy0aktzYxeL6hfur8Z1ZO/Afd5Zb3YMnOyZJ6dVRZ7Zqy+EBRv/fW8+NI GCPlhdX7wWbuKnHn68SM4tD3WnClhF5m4tJb6q4H3peUj4APzjI2vOedOgo/nog4 Cjuo= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=IbaxY+H+URVk8UfABjWUiLDr5/xzOl6PIYHrL/Iv9sgwAtaZCbgta8YbKydT0A OTiIvK2djuyE86aUA/B4L7vbnsGUBpLm11FtJgbPQrBou78JICx8A9k71ec+WNaV JW9YTZph6Fk2bcngW1+Lp42zMfCrPTHii4iUYEf+wXAoQ=; Received: (qmail 604 invoked by alias); 20 Feb 2012 21:11:24 -0000 Received: (qmail 591 invoked by uid 22791); 20 Feb 2012 21:11:23 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM, SUBJ_OBFU_PUNCT_FEW X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Feb 2012 21:11:07 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1RzaVm-0001L6-6V from Bernd_Schmidt@mentor.com for gcc-patches@gcc.gnu.org; Mon, 20 Feb 2012 13:11:06 -0800 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 13:11:06 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.1.289.1; Mon, 20 Feb 2012 21:11:03 +0000 Message-ID: <4F42B6CF.7060804@codesourcery.com> Date: Mon, 20 Feb 2012 22:10:39 +0100 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110920 Lightning/1.0b3pre Thunderbird/3.1.12 MIME-Version: 1.0 To: GCC Patches Subject: IRA: Fix WORDS_BIG_ENDIAN usage 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 For C6X, I added a patch to separate out a REG_WORDS_BIG_ENDIAN macro from WORDS_BIG_ENDIAN. Since the patch was originally for 4.5, it missed a few new instances in IRA where we need to change which macro we use. The following patch makes big-endian kernels boot. Bootstrapped and regression tested on i686-linux; can't affect any target other than C6X. Normally I'd check it in as obvious, but given that we're in stage4 I'll ask for an OK. Bernd * ira.c (check_allocation): Use REG_WORDS_BIG_ENDIAN, not WORDS_BIG_ENDIAN. * ira-color.c (setup_profitable_hard_regs, check_hard_reg_p, assign_hard_reg): Likewise. Index: gcc/ira.c =================================================================== --- gcc/ira.c (revision 183969) +++ gcc/ira.c (working copy) @@ -2089,7 +2089,7 @@ check_allocation (void) int this_regno = hard_regno; if (n > 1) { - if (WORDS_BIG_ENDIAN) + if (REG_WORDS_BIG_ENDIAN) this_regno += n - i - 1; else this_regno += i; @@ -2108,7 +2108,7 @@ check_allocation (void) if (ALLOCNO_NUM_OBJECTS (conflict_a) > 1 && conflict_nregs == ALLOCNO_NUM_OBJECTS (conflict_a)) { - if (WORDS_BIG_ENDIAN) + if (REG_WORDS_BIG_ENDIAN) conflict_hard_regno += (ALLOCNO_NUM_OBJECTS (conflict_a) - OBJECT_SUBWORD (conflict_obj) - 1); else Index: gcc/ira-color.c =================================================================== --- gcc/ira-color.c (revision 183969) +++ gcc/ira-color.c (working copy) @@ -1067,7 +1067,7 @@ setup_profitable_hard_regs (void) { int num = OBJECT_SUBWORD (conflict_obj); - if (WORDS_BIG_ENDIAN) + if (REG_WORDS_BIG_ENDIAN) CLEAR_HARD_REG_BIT (ALLOCNO_COLOR_DATA (conflict_a)->profitable_hard_regs, hard_regno + nobj - num - 1); @@ -1451,7 +1451,7 @@ check_hard_reg_p (ira_allocno_t a, int h if (nregs == nwords) { - if (WORDS_BIG_ENDIAN) + if (REG_WORDS_BIG_ENDIAN) set_to_test_start = nwords - j - 1; else set_to_test_start = j; @@ -1610,7 +1610,7 @@ assign_hard_reg (ira_allocno_t a, bool r { int num = OBJECT_SUBWORD (conflict_obj); - if (WORDS_BIG_ENDIAN) + if (REG_WORDS_BIG_ENDIAN) SET_HARD_REG_BIT (conflicting_regs[word], hard_regno + n_objects - num - 1); else