From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17710 invoked by alias); 26 May 2011 10:53:45 -0000 Received: (qmail 17700 invoked by uid 22791); 26 May 2011 10:53:44 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 May 2011 10:53:29 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id B33B99AC849; Thu, 26 May 2011 12:53:28 +0200 (CEST) Date: Thu, 26 May 2011 11:24:00 -0000 From: Jan Hubicka To: Jan Hubicka Cc: Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: Better location streaming Message-ID: <20110526105328.GA10483@kam.mff.cuni.cz> References: <20110526093410.GG17175@kam.mff.cuni.cz> <20110526104542.GB14465@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110526104542.GB14465@atrey.karlin.mff.cuni.cz> User-Agent: Mutt/1.5.18 (2008-05-17) 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-05/txt/msg01998.txt.bz2 > > > > This looks all very hackish with no immediate benefit mostly because > > of the use of lto_output_string. I think what you should do instead > > is split up lto_output_string_with_length into the piece that streams > > the string itself to the string-stream and returns an index into it > > and the piece streaming the index to the specified stream. Then you > > can simply bitpack that index and the two int line / column fields. > > Hmm, I plan to optimize string streaming (since we always stream one uleb to > set it is non-NULL that can be easilly handled by assigining NULL string index > 0). How precisely you however suggest to bitpack line/column and string offset > together? > > The point is to make location info occupy not even whole byte most of time. > Adding a simple stats claims that for tramp3d 30% of time location is > undefined, 15% of time file changes, 39% of time line changes and 44% of time > column changes (on tramp3d). So assuming one byte for each uleb (that is > optimistic, of course) one need 4 bits for the changed flags + less than a byte > for the data. Situation is similar for combine.c where unknown id 10%, file > change is 0.5% and line change is 30%. Note that for tramp3d the function sections reduce in size by about 16%, decl section by about 10%. So there is some immediate benefit. Honza