From patchwork Sat Aug 18 11:10:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Bosscher X-Patchwork-Id: 178445 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 937B52C0089 for ; Sat, 18 Aug 2012 21:11:43 +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=1345893104; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: MIME-Version:Received:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=fFP1x5Xg3XuwtD+UVpr7C8K6loI=; b=YCxbWkf7a4EAclM bW2ca4ga1rR8MDVOSOuNgDp5K3LybE0VLi2D70l8qBc1fs9+NpYcrm2Ii1ks0WJl fTWyw+aTn1XhThJoQjhsFlhGECCViq/cvpjI42YVUpYInghiItv2ZwGCIZ3Beh35 NVaeTaxvj5iHJSqAlFb9oer2BoNE= 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:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=FR/VatajlCFNhnwZIu+rD1HdnM8iFO+e380kbrglmhpydYVTGQFyzMxG+Su+KV pSlxVTuY5lFdTwomJYezRJCXfov2qIPaAMvdU/t12QDzv0zsamAZdbo8/jihebZ3 qZX3Avc+Pla8iBNqYg+g5sh5hPAT3SK3p/5KnHA76HWOk=; Received: (qmail 5631 invoked by alias); 18 Aug 2012 11:11:37 -0000 Received: (qmail 5599 invoked by uid 22791); 18 Aug 2012 11:11:35 -0000 X-SWARE-Spam-Status: No, hits=-5.0 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-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 18 Aug 2012 11:11:15 +0000 Received: by lban1 with SMTP id n1so2571109lba.20 for ; Sat, 18 Aug 2012 04:11:13 -0700 (PDT) Received: by 10.112.83.97 with SMTP id p1mr3531040lby.94.1345288273566; Sat, 18 Aug 2012 04:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.32.42 with HTTP; Sat, 18 Aug 2012 04:10:52 -0700 (PDT) In-Reply-To: References: <501FA55B.7030706@gnu.org> <501FAA1E.1040000@gnu.org> From: Steven Bosscher Date: Sat, 18 Aug 2012 13:10:52 +0200 Message-ID: Subject: Re: [patch] speed up ifcvt:cond_move_convert_if_block To: Richard Guenther Cc: Paolo Bonzini , GCC Patches , "Bergner, Peter" 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 Thu, Aug 16, 2012 at 12:06 PM, Richard Guenther wrote: > On Thu, Aug 16, 2012 at 1:11 AM, Steven Bosscher wrote: >> On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini wrote: >>>> 2. sparseset has the same problem of memory clearing (for valgrind, >>>> see sparseset_alloc). >>> >>> ... only the sparse array needs this clearing, but currently we do it >>> for both. >> >> And according to the fat comment before the xcalloc, it's not even >> really needed. Why can't we just tell valgrind to treat the memory as >> defined, like in this patchlet: > > Indeed ... I suppose ok if it bootstraps / tests w/o valgrind checking and > if a cc1 builds with valgrind checking. Here's what I'll commit: Index: sparseset.c =================================================================== --- sparseset.c (revision 190474) +++ sparseset.c (working copy) @@ -30,12 +30,14 @@ unsigned int n_bytes = sizeof (struct sparseset_def) + ((n_elms - 1) * 2 * sizeof (SPARSESET_ELT_TYPE)); - /* We use xcalloc rather than xmalloc to silence some valgrind uninitialized + sparseset set = XNEWVAR(struct sparseset_def, n_bytes); + + /* Mark the sparseset as defined to silence some valgrind uninitialized read errors when accessing set->sparse[n] when "n" is not, and never has been, in the set. These uninitialized reads are expected, by design and - harmless. If this turns into a performance problem due to some future - additional users of sparseset, we can revisit this decision. */ - sparseset set = (sparseset) xcalloc (1, n_bytes); + harmless. */ + VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes)); + set->dense = &(set->elms[0]); set->sparse = &(set->elms[n_elms]); set->size = n_elms;