On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote: > On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz <m...@suse.de> 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) 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. 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. Hope this sounds sane Dave
