From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14820 invoked by alias); 14 Mar 2008 15:19:02 -0000 Received: (qmail 14768 invoked by uid 22791); 14 Mar 2008 15:19:01 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Mar 2008 15:18:43 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id m2EFIZ59023800 for ; Fri, 14 Mar 2008 15:18:35 GMT Received: from fk-out-0910.google.com (fks18.prod.google.com [10.94.19.18]) by zps37.corp.google.com with ESMTP id m2EFHo0j026170 for ; Fri, 14 Mar 2008 08:18:34 -0700 Received: by fk-out-0910.google.com with SMTP id 18so4758919fks.4 for ; Fri, 14 Mar 2008 08:18:34 -0700 (PDT) Received: by 10.78.81.20 with SMTP id e20mr30779367hub.19.1205507908791; Fri, 14 Mar 2008 08:18:28 -0700 (PDT) Received: from dhcp-172-19-57-187.corp.google.com ( [172.19.57.187]) by mx.google.com with ESMTPS id o22sm8544847hub.44.2008.03.14.08.18.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Mar 2008 08:18:28 -0700 (PDT) Message-ID: <47DA9740.8000402@google.com> Date: Fri, 14 Mar 2008 15:25:00 -0000 From: Diego Novillo User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Aldy Hernandez CC: gcc-patches@gcc.gnu.org Subject: Re: [tuples] memory statistics gathering for tuples References: <20080311191313.GA28249@redhat.com> <47D7F8B1.1060502@google.com> <20080314150008.GA24330@redhat.com> In-Reply-To: <20080314150008.GA24330@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-03/txt/msg00903.txt.bz2 On 3/14/08 8:00 AM, Aldy Hernandez wrote: >> 3- The easiest approach will probably be comparing statement lists versus >> gimple sequences. We still haven't gone through making sure we release all >> the expression trees that are gimplified. > > Yes, I'm noticing benchmarking is going to be non-trivial, and probably > not an exact science until we have exact code paths, and we can > benchmark right before RTL generation, not after gimplification like I > will be forced to do now. Yes, there are many things that have changed place, so we have to make sure we count the exact same thing in trees and tuples. While I don't expect huge memory savings, calibrating this should not be hard. If you find that tuple sizes seem bigger than trees, it's almost a certainty that the counts are not being collected right. In any case, memory savings is going to be just a side-effect of the redesign, it's not one of the important parameters in my mind. The only blocker would be if tuples result in worse memory utilization or compile-time performance. > I think comparing statement lists versus gimple sequences will be the > most straightforward way. Of course I will have to adjust the size of > tuples for extra things we have in there, like USE/DEF information, BB > information, etc. Yeah, or make sure that we also count the size of stmt_ann() in trees. And not just sizeof(), we need to add up all the sizes for individual fields in the annotation. > >>> @@ -186,9 +212,14 @@ gimple_alloc (enum gimple_code code) >>> static void >>> gimple_alloc_ops (gimple stmt, size_t num_ops) >>> { >>> - stmt->with_ops.op = ggc_alloc_cleared (sizeof (tree) * num_ops); >>> + unsigned int size = sizeof (tree) * num_ops; >> Here you're just counting the size of the pointer. You need to call >> tree_code_size for each operand added. > > Are you sure? It looks like the tree counterpart is only adding > pointers for operands. See tree_code_size: Oh, right. The operands are always counted separately in each of their own categories. Diego.