From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2942 invoked by alias); 17 Aug 2012 12:14:33 -0000 Received: (qmail 2929 invoked by uid 22791); 17 Aug 2012 12:14:32 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 17 Aug 2012 12:14:13 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7HCEDNV003063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Aug 2012 08:14:13 -0400 Received: from tucnak.redhat.com (vpn1-7-20.ams2.redhat.com [10.36.7.20]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7HCEAqa008442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 08:14:12 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id q7HC8xfs031073; Fri, 17 Aug 2012 14:09:00 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id q7HC8xZO031072; Fri, 17 Aug 2012 14:08:59 +0200 Date: Fri, 17 Aug 2012 12:14:00 -0000 From: Jakub Jelinek To: Steven Bosscher Cc: Richard Guenther , GCC Patches Subject: Re: [patch][RFC] 160-bits bitmap_element Message-ID: <20120817120859.GT1999@tucnak.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 X-SW-Source: 2012-08/txt/msg01155.txt.bz2 On Fri, Aug 17, 2012 at 02:04:50PM +0200, Steven Bosscher wrote: > On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther > wrote: > > Well, another effect of reducing the size of BITMAP_WORD is that > > operations are not performed in a mode optimally using CPU regs > > (did you check code generation differences on a 64bit host?). > > I did, on x86_64 and on powerpc64. The effect is not dramatic, most of > these machines can perform 32 bits operations just fine (I think the > only exception would be alpha, maybe?). One this is testing a bit in a bitmap or setting it, except for old alpha I guess it shouldn't be noticeable. But then there are functions that iterate over the bitmap, where using larger type should be noticeable (I mean stuff like bitmap copying, logical operations on whole bitmap, etc.). Jakub