From patchwork Wed Jan 9 22:57:00 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Stump X-Patchwork-Id: 210889 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 559F72C01C8 for ; Thu, 10 Jan 2013 09:57:20 +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=1358377041; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=L/g2oNBSMJesNcGkjQEX G+9Njx4=; b=NVdvFNcYq7IADqAheIhtgFlaERAtAdwJddECpkpK3lIuQ481tAaf LWrCYS6LAAhXqH4uVLUyNIH/mZkv3q1SARIxZmvr37yYESSBE6i+6sfhaAY4rPLs 0T8n3JIiL1IKJB1ZkZWjEB9XrAYBDldMUo05pf9XGnnc5PGhH3Vpjqk= 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:From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=W3Z/nZET3N1cUORK2pFIDRFMCm2jtijqR5tcRICp2jkOR3YuS9PcpgzOppEwT9 Ddq8la+yjBKejnyKRHO5/ohSLx+MMxNZjdcihp4a7AFVGtz3iHJstsYgL+jixQ7E wfYWauBHAPrlMy6o583Y8UVpCfq8IOd1dSzW/LOxOWEUQ=; Received: (qmail 4280 invoked by alias); 9 Jan 2013 22:57:11 -0000 Received: (qmail 4271 invoked by uid 22791); 9 Jan 2013 22:57:10 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_HOSTKARMA_NO, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta13.westchester.pa.mail.comcast.net (HELO qmta13.westchester.pa.mail.comcast.net) (76.96.59.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Jan 2013 22:57:03 +0000 Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id lpiX1k0011swQuc5Dyx3sd; Wed, 09 Jan 2013 22:57:03 +0000 Received: from bag6-1-pt.tunnel.tserv3.fmt2.ipv6.he.net ([IPv6:2001:470:1f04:ae1::2]) by omta15.westchester.pa.mail.comcast.net with comcast id lyx11k00M0P3DwE3byx2us; Wed, 09 Jan 2013 22:57:03 +0000 From: Mike Stump Subject: unnecessary assert Date: Wed, 9 Jan 2013 14:57:00 -0800 Message-Id: <55327D81-C743-4A22-890C-3FD6AC859577@comcast.net> Cc: Jakub Jelinek , Diego Novillo To: "gcc-patches@gcc.gnu.org Patches" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) 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 I found an assert that trips on my port for trivial constructs, often. I'd like to remove it, so that my port works better. The assert was added because the case analysis he did was for when BLKmode MEM stores appeared in back when he wrote the patch (Hi Jakub). He didn't analyze when dealing with a non-BLKmode. I've been through the code, and it previously handled non-BLKmode when the size was <= HOST_BITS_PER_WIDE_INT, so, I don't worry about that aspect of it. Indeed, the very assert was originally directly above code that was not more than HOST_BITS_PER_WIDE_INT bits safe: - gcc_assert ((unsigned) width <= HOST_BITS_PER_WIDE_INT); - /* Finish filling in the store_info. */ store_info->next = insn_info->store_rec; insn_info->store_rec = store_info; store_info->mem = canon_rtx (mem); store_info->alias_set = spill_alias_set; store_info->mem_addr = get_addr (XEXP (mem, 0)); store_info->cse_base = base; - store_info->positions_needed = lowpart_bitmask (width); + if (width > HOST_BITS_PER_WIDE_INT) + { + store_info->is_large = true; + store_info->positions_needed.large.count = 0; + store_info->positions_needed.large.bitmap = BITMAP_ALLOC (NULL); + } + else + { + store_info->is_large = false; + store_info->positions_needed.small_bitmask = lowpart_bitmask (width); + } The new code in that patch added support for BLKmode with sizes > HOST_BITS_PER_WIDE_INT. The assert was to protect the positions_needed, as it wasn't big enough to handle any data larger than HOST_BITS_PER_WIDE_INT. The previous patch now supports larger data and mediates access to positions_needed based upon is_large, which is necessary. The only outstanding question is, is there any other aspect of the code that needs to now check is_large, that doesn't. I've looked and did not find any other such code. [ digging ] Ah, the original assert was added in: svn+ssh://gcc.gnu.org/svn/gcc/trunk@134199 and merely protected positions_needed, as I suspected. Ok? Ok for 2.8? http://gcc.gnu.org/PR31150 is the PR when the assert was added, if you want to see it. svn+ssh://gcc.gnu.org/svn/gcc/trunk@142892 is the change itself. 2013-01-09 Mike Stump * dse.c (record_store): Remove unnecessary assert. 2013-01-09 Mike Stump * dse.c (record_store): Remove unnecessary assert. Index: dse.c =================================================================== --- dse.c (revision 195067) +++ dse.c (working copy) @@ -1495,10 +1495,7 @@ record_store (rtx body, bb_info_t bb_inf if (GET_MODE (mem) == BLKmode) width = MEM_SIZE (mem); else - { - width = GET_MODE_SIZE (GET_MODE (mem)); - gcc_assert ((unsigned) width <= HOST_BITS_PER_WIDE_INT); - } + width = GET_MODE_SIZE (GET_MODE (mem)); if (spill_alias_set) {