From patchwork Thu Jul 1 03:17:48 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: DJ Delorie X-Patchwork-Id: 57462 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 450691007D2 for ; Thu, 1 Jul 2010 13:18:03 +1000 (EST) Received: (qmail 14664 invoked by alias); 1 Jul 2010 03:18:01 -0000 Received: (qmail 14653 invoked by uid 22791); 1 Jul 2010 03:18:01 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Jul 2010 03:17:53 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o613HpLu024755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2010 23:17:51 -0400 Received: from greed.delorie.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o613Hn4s001145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Jun 2010 23:17:51 -0400 Received: from greed.delorie.com (greed.delorie.com [127.0.0.1] (may be forged)) by greed.delorie.com (8.14.3/8.14.3) with ESMTP id o613HmZ1016054 for ; Wed, 30 Jun 2010 23:17:48 -0400 Received: (from dj@localhost) by greed.delorie.com (8.14.3/8.14.3/Submit) id o613HmhD016051; Wed, 30 Jun 2010 23:17:48 -0400 Date: Wed, 30 Jun 2010 23:17:48 -0400 Message-Id: <201007010317.o613HmhD016051@greed.delorie.com> From: DJ Delorie To: gcc-patches@gcc.gnu.org Subject: canonicalize_condition vs zero_extract 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 If you have an insn that does "test ,", gcc will look for a pattern that uses zero_extract to generate the "condition" when is a power of two. However, canincalize_condition gets passed this condition, and only expects the RTL at this point to have two subexpressions. Zero_extract has three, so it blows up: return gen_rtx_fmt_ee (code, VOIDmode, op0, op1); This is a simple check for this case, but is it the right solution? Would it be better to: * Check for a generic "this rtl has more than 2 xexp's"? * Check for the codes we know, and return 0 for the rest? * Find out why a zero_extract is getting this far in the first place? Index: rtlanal.c =================================================================== --- rtlanal.c (revision 161641) +++ rtlanal.c (working copy) @@ -4699,12 +4699,15 @@ canonicalize_condition (rtx insn, rtx co code = GET_CODE (cond); mode = GET_MODE (cond); op0 = XEXP (cond, 0); op1 = XEXP (cond, 1); + if (code == ZERO_EXTRACT) + return 0; + if (reverse) code = reversed_comparison_code (cond, insn); if (code == UNKNOWN) return 0; if (earliest)