From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3539 invoked by alias); 22 Oct 2004 19:33:33 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 3525 invoked from network); 22 Oct 2004 19:33:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 22 Oct 2004 19:33:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id i9MJXPU5025487; Fri, 22 Oct 2004 15:33:30 -0400 Received: from [172.16.83.146] (vpn83-146.boston.redhat.com [172.16.83.146]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9MJXOr07663; Fri, 22 Oct 2004 15:33:25 -0400 Subject: Re: [patch] sbitmap.h: Speed up EXECUTE_IF_SET_IN_SBITMAP. From: Jeffrey A Law Reply-To: law@redhat.com To: Kazu Hirata Cc: rth@redhat.com, gcc-patches@gcc.gnu.org In-Reply-To: <20041019.221038.59463737.kazu@cs.umass.edu> References: <20041018.172213.59683982.kazu@cs.umass.edu> <20041019231618.GF19976@redhat.com> <20041019.221038.59463737.kazu@cs.umass.edu> Content-Type: text/plain Organization: Red Hat, Inc Message-Id: <1098473603.2915.224.camel@localhost.localdomain> Mime-Version: 1.0 Date: Fri, 22 Oct 2004 19:51:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg01957.txt.bz2 On Tue, 2004-10-19 at 20:10, Kazu Hirata wrote: > Hi Richard, > > > > SBITMAP_ELT_TYPE *ptr_ = (SBITMAP)->elms; \ > > > \ > > > ! for (word_num_ = (MIN) / (unsigned int) SBITMAP_ELT_BITS; \ > > > ! word_num_ < size_; word_num_++, bit_num_ = 0) \ > > > { \ > > > ! SBITMAP_ELT_TYPE word_ = ptr_[word_num_]; \ > > [...] > > > + SBITMAP_ELT_TYPE word_ = ptr_[word_num_] >> bit_num_; \ > > > > Previously, setting MIN arbitrarily large would not read from PTR; > > now it does. I think this is a faulty translation of this function. > > oops. I found another problem of accessing PTR beyond its end. Note > that I check for the end condition *after* I increment word_num and > get a new word_ like so. > > for (; \ > word_num_ < size_; \ > word_num_++, bit_num_ = 0, word_ = ptr_[word_num_]) \ > > I'll be testing the patch below shortly. The end result is a bit > ugly, but there shouldn't be any performance loss. OK to apply if > testing passes? > > Kazu Hirata > > 2004-10-19 Kazu Hirata > > * sbitmap.h (EXECUTE_IF_SET_IN_SBITMAP): Don't access PTR > beyond its end. This is OK assuming it passed regression testing. jeff