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. Richard. > > Ciao, > Michael.
