From patchwork Sat Mar 10 08:11:11 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chung-Lin Tang X-Patchwork-Id: 145844 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 6C48EB6F13 for ; Sat, 10 Mar 2012 19:11:38 +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=1331971899; 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=oLs/U3F 2VRGJ7EdvaxA0FQ90bY8=; b=HKo98bsG0msqIuQWVjlsr++k1fImN4FXMEd+HWg lPEOt5s1brrkQqE1+7DwgeeRwssah7sBMva+YVL328jicpFMdZNy4CuUXdO00nVz oNw9uzLyc4Z4o7PHSFErjwhaSg+DT9YifVTNoVdU1dsUUOaC6Ovi00IPlyA4E48V MYG4= 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:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=d4vMWqW4HApQZIZ0uZvGW3GFbetWBPixYVgLYYL/1D5lFKmq/OPe1bFT4Efp7c CwSLKd1vFSgcDvivrzj3ep0mPKs1svEtdGwc9PUVuVhoNzIxayxilTkGzoHef9Om 8AVGULDM16ha76gKOFO5AeAafcuIr4YzipNE3ytuj1Pb0=; Received: (qmail 13912 invoked by alias); 10 Mar 2012 08:11:21 -0000 Received: (qmail 13899 invoked by uid 22791); 10 Mar 2012 08:11:13 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM, TW_CR, TW_RX 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; Sat, 10 Mar 2012 08:10:59 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1S6HOD-0005Hg-Kk from ChungLin_Tang@mentor.com for gcc-patches@gcc.gnu.org; Sat, 10 Mar 2012 00:10:57 -0800 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Mar 2012 00:10:57 -0800 Received: from [0.0.0.0] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.1.289.1; Sat, 10 Mar 2012 00:10:56 -0800 Message-ID: <4F5B0C9F.3010001@codesourcery.com> Date: Sat, 10 Mar 2012 16:11:11 +0800 From: Chung-Lin Tang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: gcc-patches Subject: [PATCH] PR52528, combine fix X-IsSubscribed: yes 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 Hi, As described in the PR, a testcase compiled for PowerPC: struct S { unsigned a : 30; unsigned b : 2; }; int foo (int b) { struct S s = {0}; s.b = b; return bar (0x000b0010, 0x00040100ULL, *(unsigned long *)&s); } currently this is compiled to: foo: lis 6,0x4 li 5,0 ori 6,6,256 li 7,0 crxor 6,6,6 b bar Notice the incorrect code generated: no construction of the 1st arg (reg 3), and wrong code for the 3rd arg (reg 7) The problem seems to be in combine, during calls from try_combine() to can_combine_p(): can_combine_p() has a call to expand_field_assignment(), which may call get_last_value() during its simplification operations (through the reg_nonzero_bits_for_combine() hook); not setting subst_low_luid properly affects its correctness. So the fix is a one-liner that sets subst_low_luid before the expand_field_assignment() call. Bootstrapped and tested under i686, x86-64, powerpc64. Cross-tested on ARM. I was a bit weary that some optimization regression might appear, which will complicate things, but everything looks fine. I have a larger (customer provided) testcase that exposed this bug after rev.161655 (the mem-ref2 merge, may be related to effects on bitfields). So if suitable, please also approve this patch for 4.6/4.7 branches. Thanks, Chung-Lin 2012-03-10 Chung-Lin Tang PR rtl-optimization/52528 * combine.c (can_combine_p): Add setting of subst_low_luid before call to expand_field_assignment(). Index: combine.c =================================================================== --- combine.c (revision 185168) +++ combine.c (working copy) @@ -1822,6 +1822,10 @@ can_combine_p (rtx insn, rtx i3, rtx pred ATTRIBUT if (set == 0) return 0; + /* The simplification in expand_field_assignment() may call back to + get_last_value(), so set safe guard here. */ + subst_low_luid = DF_INSN_LUID (insn); + set = expand_field_assignment (set); src = SET_SRC (set), dest = SET_DEST (set);