From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63865 invoked by alias); 15 Apr 2015 12:27:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 63822 invoked by uid 89); 15 Apr 2015 12:27:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Apr 2015 12:26:59 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id B323932B476 for ; Wed, 15 Apr 2015 12:26:58 +0000 (UTC) Received: from localhost.localdomain ([10.3.113.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3FCQwaH008382 for ; Wed, 15 Apr 2015 08:26:58 -0400 Message-ID: <552E5912.8050801@redhat.com> Date: Wed, 15 Apr 2015 12:27:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: gcc-patches Subject: Fwd: [PATCH][PR rtl-optimization/42522] Incorrect simplification of ZERO_EXTRACT and SIGN_EXTRACT by cse References: <54D53AAB.4010605@redhat.com> In-Reply-To: <54D53AAB.4010605@redhat.com> X-Forwarded-Message-Id: <54D53AAB.4010605@redhat.com> Content-Type: multipart/mixed; boundary="------------010301010704090708020709" X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00751.txt.bz2 This is a multi-part message in MIME format. --------------010301010704090708020709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1584 I've bootstrapped and regression tested this patch on x86_64-linux-gnu and committed it to the trunk. The bug is latent on the reported target (m68k), so no testcase. -------- Forwarded Message -------- Subject: [PATCH][PR rtl-optimization/42522] Incorrect simplification of ZERO_EXTRACT and SIGN_EXTRACT by cse Date: Fri, 06 Feb 2015 15:05:31 -0700 From: Jeff Law To: gcc-patches This bug has gone latent on the trunk; however, the problem still remains that cse will incorrectly simplify a ZERO/SIGN_EXTRACT in some cases. ZERO/SIGN_EXTRACT are somewhat special in that if they are extracting from a memory operand, that memory operand will always have QImode regardless of the size of the extracted field. ie, the mode of the MEM in a ZERO/SIGN_EXTRACT does not really mean anything and the ZERO/SIGN_EXTRACT can read bits beyond QImode. So given a (mem:QI x) with an equivalence to (const_int 0) in the hash tables. If we have an extraction like (zero_extract:SI (mem:QI x) (const_int 0) (const_int 24)) CSE will substitute (const_int 0) for the MEM in the extraction resulting in (zero_extract:SI (const_int 0) (const_int 0) (const_int 24)) Which simplifies to (const_int 0) For REGs, the mode is the same as the operand of the insv/extv pattern, and may (or may not) more closely resemble reality depending on the target. The safe thing to do in CSE is to lookup the ZERO/SIGN_EXTRACT as a whole. Given the bug is latent and not currently a regression this will need to wait for the next stage1 development cycle. --------------010301010704090708020709 Content-Type: text/plain; charset=UTF-8; name="P" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="P" Content-length: 792 diff --git a/gcc/cse.c b/gcc/cse.c index f7b477c..8ab48c4 100644 --- a/gcc/cse.c +++ b/gcc/cse.c @@ -3178,6 +3178,15 @@ fold_rtx (rtx x, rtx insn) { case MEM: case SUBREG: + /* The first operand of a SIGN/ZERO_EXTRACT has a different meaning + than it would in other contexts. Basically its mode does not + signify the size of the object read. That information is carried + by size operand. If we happen to have a MEM of the appropriate + mode in our tables with a constant value we could simplify the + extraction incorrectly if we allowed substitution of that value + for the MEM. */ + case ZERO_EXTRACT: + case SIGN_EXTRACT: if ((new_rtx = equiv_constant (x)) != NULL_RTX) return new_rtx; return x; --------------010301010704090708020709--