From patchwork Wed Aug 15 23:11:43 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Bosscher X-Patchwork-Id: 177879 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 ABBC82C008D for ; Thu, 16 Aug 2012 09:12:24 +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=1345677144; 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=gxMG3a7VbVHWSUCA6oAm8+9cWaE=; b=fUKiEd7qMMyonKR k2QXefTorGe1ubpkgW3cSKI93OACV/soQJm+KGNpK+i0IrhBqhdz+7yime3U6qV5 7xsnBs5FDt7FwgL8fKS5WrnGIYSCKfk2heCyQzDwZQfRTI3qQSu3CNLwkw4ITRsi Fn718a1NuHvHWMKL8/w5t1OIGC0k= 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=cmi3ArFMBzSr8IrEJdcQyhuZQU+N8PqhNF+Ks5fNouedGSbLIPeOEc5Hg5j/17 IvIKYTm3xlGK7fHBYKEEEXmQgqlbvnmUfJKwgX/UO+rCgOtA3qf23YE+SH5WQlNn 0x9SrJ9H3pvScuANpvQr2W6pEJpmJ8xlLDkv9IU5Kphwo=; Received: (qmail 14944 invoked by alias); 15 Aug 2012 23:12:19 -0000 Received: (qmail 14930 invoked by uid 22791); 15 Aug 2012 23:12:18 -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; Wed, 15 Aug 2012 23:12:05 +0000 Received: by lban1 with SMTP id n1so1191302lba.20 for ; Wed, 15 Aug 2012 16:12:03 -0700 (PDT) Received: by 10.112.29.233 with SMTP id n9mr10155181lbh.91.1345072323578; Wed, 15 Aug 2012 16:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.32.42 with HTTP; Wed, 15 Aug 2012 16:11:43 -0700 (PDT) In-Reply-To: <501FAA1E.1040000@gnu.org> References: <501FA55B.7030706@gnu.org> <501FAA1E.1040000@gnu.org> From: Steven Bosscher Date: Thu, 16 Aug 2012 01:11:43 +0200 Message-ID: Subject: Re: [patch] speed up ifcvt:cond_move_convert_if_block To: Paolo Bonzini Cc: 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 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: I have never built GCC with valgrind checking, so I don't know if this is correct. But there has to be a better solution than calling xcalloc... Ciao! Steven Index: sparseset.c =================================================================== --- sparseset.c (revision 190418) +++ sparseset.c (working copy) @@ -30,12 +30,14 @@ sparseset_alloc (SPARSESET_ELT_TYPE n_elms) 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(sparseset, 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;