From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60498 invoked by alias); 24 Sep 2015 08:15:09 -0000 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 Received: (qmail 60478 invoked by uid 89); 24 Sep 2015 08:15:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f169.google.com Received: from mail-yk0-f169.google.com (HELO mail-yk0-f169.google.com) (209.85.160.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 24 Sep 2015 08:15:06 +0000 Received: by ykdg206 with SMTP id g206so68326960ykd.1 for ; Thu, 24 Sep 2015 01:15:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.104.139 with SMTP id d133mr27702877ywc.94.1443082504119; Thu, 24 Sep 2015 01:15:04 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Thu, 24 Sep 2015 01:15:04 -0700 (PDT) In-Reply-To: <1443054335.30732.42.camel@surprise> References: <1442957171-22904-1-git-send-email-dmalcolm@redhat.com> <1443054335.30732.42.camel@surprise> Date: Thu, 24 Sep 2015 09:03:00 -0000 Message-ID: Subject: Re: [PATCH 0/5] RFC: Overhaul of diagnostics (v2) From: Richard Biener To: David Malcolm Cc: Michael Matz , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01829.txt.bz2 On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote: > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote: >> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote: >> > Hi, >> > >> > On Tue, 22 Sep 2015, David Malcolm wrote: >> > >> >> The drawback is that it could bloat the ad-hoc table. Can the ad-hoc >> >> table ever get smaller, or does it only ever get inserted into? >> > >> > It only ever grows. >> > >> >> An idea I had is that we could stash short ranges directly into the 32 >> >> bits of location_t, by offsetting the per-column-bits somewhat. >> > >> > It's certainly worth an experiment: let's say you restrict yourself to >> > tokens less than 8 characters, you need an additional 3 bits (using one >> > value, e.g. zero, as the escape value). That leaves 20 bits for the line >> > numbers (for the normal 8 bit columns), which might be enough for most >> > single-file compilations. For LTO compilation this often won't be enough. >> > >> >> My plan is to investigate the impact these patches have on the time and >> >> memory consumption of the compiler, >> > >> > When you do so, make sure you're also measuring an LTO compilation with >> > debug info of something big (firefox). I know that we already had issues >> > with the size of the linemap data in the past for these cases (probably >> > when we added columns). >> >> The issue we have with LTO is that the linemap gets populated in quite >> random order and thus we repeatedly switch files (we've mitigated this >> somewhat for GCC 5). We also considered dropping column info >> (and would drop range info) as diagnostics are from optimizers only >> with LTO and we keep locations merely for debug info. > > Thanks. Presumably the mitigation you're referring to is the > lto_location_cache class in lto-streamer-in.c? > > Am I right in thinking that, right now, the LTO code doesn't support > ad-hoc locations? (presumably the block pointers only need to exist > during optimization, which happens after the serialization) LTO code does support ad-hoc locations but they are "restored" only when reading function bodies and stmts (by means of COMBINE_LOCATION_DATA). > The obvious simplification would be, as you suggest, to not bother > storing range information with LTO, falling back to just the existing > representation. Then there's no need to extend LTO to serialize ad-hoc > data; simply store the underlying locus into the bit stream. I think > that this happens already: lto-streamer-out.c calls expand_location and > stores the result, so presumably any ad-hoc location_t values made by > the v2 patches would have dropped their range data there when I ran the > test suite. Yep. We only preserve BLOCKs, so if you don't add extra code to preserve ranges they'll be "dropped". > If it's acceptable to not bother with ranges for LTO, one way to do the > "stashing short ranges into the location_t" idea might be for the > bits-per-range of location_t values to be a property of the line_table > (or possibly the line map), set up when the struct line_maps is created. > For non-LTO it could be some tuned value (maybe from a param?); for LTO > it could be zero, so that we have as many bits as before for line/column > data. That could be a possibility (likewise for column info?) Richard. > Hope this sounds sane > Dave >