From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29735 invoked by alias); 28 Apr 2011 18:25:04 -0000 Received: (qmail 29719 invoked by uid 22791); 28 Apr 2011 18:25:03 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Apr 2011 18:24:49 +0000 Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p3SIOmAd017815 for ; Thu, 28 Apr 2011 11:24:48 -0700 Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by kpbe12.cbf.corp.google.com with ESMTP id p3SIO0Ma014716 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 28 Apr 2011 11:24:47 -0700 Received: by gyg13 with SMTP id 13so1487170gyg.13 for ; Thu, 28 Apr 2011 11:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.190.6 with SMTP id s6mr2591841anp.20.1304015086941; Thu, 28 Apr 2011 11:24:46 -0700 (PDT) Received: by 10.100.131.8 with HTTP; Thu, 28 Apr 2011 11:24:46 -0700 (PDT) In-Reply-To: References: <20110428180401.27B35481B0@thebrac.mtv.corp.google.com> Date: Thu, 28 Apr 2011 18:53:00 -0000 Message-ID: Subject: Re: [google][patch] Track discriminators by instruction instead of by basic block (issue4441075) From: Cary Coutant To: Diego Novillo Cc: reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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: 2011-04/txt/msg02256.txt.bz2 >> =A0 =A0Rework discriminator assignment so that it attaches the discrimin= ator >> =A0 =A0to the source location of each instruction instead of to the basic >> =A0 =A0block itself. > > Any idea on how this affects memory consumption? Richard had the same question when I first proposed this patch. This was my answer then: "Not a lot. We assign discriminators for only a small fraction of the total number of locations in the program, so the number of unique location_t values doesn't increase significantly. I didn't add anything to the line_map structure, nor did I do anything at all in libcpp, so it's not bloating the source_location/location_t data structures at all. The extra space needed is linear with the number of discriminators assigned, which is roughly one per for loop or switch statement, plus an occasional discriminator for conditional expressions or macro expansions with control flow. (In the old code that I'm replacing, the extra space was one int per basic block.)" >> =A0 =A0It's not ready for trunk yet because it does not yet preserve >> =A0 =A0the discriminators across LTO, so I'd like to put it in >> =A0 =A0google/main until I have a chance to get that part working. > > But, IIRC this does not introduce LTO regressions, right? Right. Even though discriminators don't survive the streaming-out/streaming-in process, the samples obtained from an initial non-LTO compilation will include discriminator information, and that information survives long enough into a profile-use compilation with LTO for the frequency information to get recorded correctly. -cary