From patchwork Fri Aug 17 12:12:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 178194 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 4B86A2C008B for ; Fri, 17 Aug 2012 22:13:15 +1000 (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=1345810396; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=/HLLbUd6Zyg2LuE4nLCQzPHw0vg=; b=aTzsrnn51tFSdtye8waB2PB5LXbGfhJnboNt90xGnqJe79JRtHo3vGDwOWfw4U nBCZg89RQP91buzMTg8YIBVbz+EnPhsvcxy3C5O+wZh1ypUIYZZCDS3hr9diEeOa WuAMBwIfOm+Tilids0Rauzbqcdxl3unVHFpHfoQq0rNGE= 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:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=TBFSIq/EKvO+E4oLp5En8uuHaIswOWjxQyBdYIR4RBz2JkPIYpq3AFOTfbgcZP aa/doWFNy41IsSyY8FnFgultd7dxvUaQi4XA/5ItfoVh0r0s2JKnvsloxU/2/Fyh nFbPhhp11f9uEFv5z0QJLDjrjpzbFlB2CTyHcZ0s5JoZs=; Received: (qmail 2048 invoked by alias); 17 Aug 2012 12:13:09 -0000 Received: (qmail 2038 invoked by uid 22791); 17 Aug 2012 12:13:08 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Aug 2012 12:12:55 +0000 Received: by obc16 with SMTP id 16so5689801obc.20 for ; Fri, 17 Aug 2012 05:12:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.171.174 with SMTP id av14mr3787753oec.61.1345205574547; Fri, 17 Aug 2012 05:12:54 -0700 (PDT) Received: by 10.76.9.200 with HTTP; Fri, 17 Aug 2012 05:12:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Aug 2012 14:12:54 +0200 Message-ID: Subject: Re: [patch][RFC] 160-bits bitmap_element From: Richard Guenther To: Steven Bosscher Cc: GCC Patches , Jakub Jelinek 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 On Fri, Aug 17, 2012 at 2:04 PM, 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?). I wonder how bad code gets when we unconditionally use GCCs generic vector support to do able to lower it to the same scalar code or even v2si operations where only those are available ... Just an idea and eventually an opportunity to improve generic vector lowering if the above really does not work out. Richard. > Ciao! > Steven Index: gcc/bitmap.c =================================================================== --- gcc/bitmap.c (revision 190469) +++ gcc/bitmap.c (working copy) @@ -1446,6 +1446,17 @@ bitmap_compl_and_into (bitmap a, const_b unsigned ix; BITMAP_WORD ior = 0; +#if BITMAP_ELEMENT_WORDS == 5 + typedef v4si unsigned int __attribute__((vector_size((16)))); + v4si cleared4 = *(v4si *)&a_elt->bits[0] & *(v4si *)&b_elt->bits[0]; + BITMAP_WORD cleared5 = a_elt->bits[4] & b_elt->bits[4]; + v4si r4 = *(v4si *)&b_elt->bits[0] ^ cleared4; + BITMAP_WORD r5 = b_elt->bits[4] ^ cleared5; + *(v4si *)&a_elt->bits[0] = r4; + a_elt->bits[4] = r5; + ior4 |= r4; + ior5 |= r5; +#else for (ix = 0; ix < BITMAP_ELEMENT_WORDS; ix++) of course with a proper #if GCC_VERSION. The theory is we should be