[Bug lto/65536] LTO line number information garbled

["manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536

--- Comment #12 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> You could just stream another table, containing the { file, line, column }
> triplets, and stream location_t as indexes into this table (with 0/1 being
> special for UNKNOWN_LOCATION and BUILTINS_LOCATION), or as pairs {
> location_t, block }.  Then on LTO reading, you could perhaps read the
> location tables from multiple source files, merge them and for each of the
> TUs build a hash_map mapping from the table indexes to location_t values.

That is a bit of waste of memory, no? The "{ file, line, column }" table might
be huge, presumably much larger than the actual line_tables. Thus, why not just
stream the line_tables directly? Then, you can stream the location_t as they
are.

When reading, it is possible to merge different TU line_tables into a single
one quite efficiently (in the order of the maps and not in the order of
triplets or maximum location_t). When adding each new TU line_table to the
unified one, one keeps track of the last location_t assigned, and uses this
later to convert out of order the old location_t from each TU line_table to the
new location_t of the new unified line_table.

Perhaps I'm missing some detail and Dodji can comment on this idea.