From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6014 invoked by alias); 6 May 2016 21:18:46 -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 6004 invoked by uid 89); 6 May 2016 21:18:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Fri, 06 May 2016 21:18:44 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 50D5863169 for ; Fri, 6 May 2016 21:18:43 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-64.phx2.redhat.com [10.3.113.64]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u46LIhx5007777 for ; Fri, 6 May 2016 17:18:43 -0400 From: Jeff Law To: gcc-patches Subject: [RFA] Remove useless test in bitmap_find_bit. Message-ID: Date: Fri, 06 May 2016 21:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------92FC5B3A6BDB5061B1A92342" X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00540.txt.bz2 This is a multi-part message in MIME format. --------------92FC5B3A6BDB5061B1A92342 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 849 I was looking at a performance regression with some threading changes I'm working on and spotted this trivial cleanup. in bitmap_find_bit: /* `element' is the nearest to the one we want. If it's not the one we want, the one we want doesn't exist. */ head->current = element; head->indx = element->indx; if (element != 0 && element->indx != indx) element = 0; ELEMENT will always be non-NULL at the conditional as it was dereferenced in the prior statement. And if we look up further (not shown here), we can deduce that ELEMENT will always be non-NULL at the dereference point as well. Things have been like this since the introduction of bitmap.c in 1997. VRP will catch this, but its kind of silly to not clean this nit up at the source level. Bootstrapped and regression tested on x86_64 linux. OK for the trunk? --------------92FC5B3A6BDB5061B1A92342 Content-Type: text/plain; charset=UTF-8; name="P" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="P" Content-length: 615 CSogYml0bWFwLmMgKGJpdG1hcF9maW5kX2JpdCk6IFJlbW92ZSB1c2VsZXNz IHRlc3QuCgpkaWZmIC0tZ2l0IGEvZ2NjL2JpdG1hcC5jIGIvZ2NjL2JpdG1h cC5jCmluZGV4IDBjMDU1MTIuLjAxMGNmNzUgMTAwNjQ0Ci0tLSBhL2djYy9i aXRtYXAuYworKysgYi9nY2MvYml0bWFwLmMKQEAgLTU1Niw3ICs1NTYsNyBA QCBiaXRtYXBfZmluZF9iaXQgKGJpdG1hcCBoZWFkLCB1bnNpZ25lZCBpbnQg Yml0KQogICAgICB3YW50LCB0aGUgb25lIHdlIHdhbnQgZG9lc24ndCBleGlz dC4gICovCiAgIGhlYWQtPmN1cnJlbnQgPSBlbGVtZW50OwogICBoZWFkLT5p bmR4ID0gZWxlbWVudC0+aW5keDsKLSAgaWYgKGVsZW1lbnQgIT0gMCAmJiBl bGVtZW50LT5pbmR4ICE9IGluZHgpCisgIGlmIChlbGVtZW50LT5pbmR4ICE9 IGluZHgpCiAgICAgZWxlbWVudCA9IDA7CiAKICAgcmV0dXJuIGVsZW1lbnQ7 Cg== --------------92FC5B3A6BDB5061B1A92342--