[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 #15 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> By streaming the line_table directly you'd stream lots of location_t that
> are not actually used for anything that is streamed into the LTO.
> I don't understand why the tables would be huge, the string would of course
> use normal LTO section string sharing, and if we stream right now every
> location_t as the triplet, it would mean in case a single location_t is
> never used by more than one tree we'd stream an integer extra to what we
> stream now (just the triplets would be streamed in a different place), but
> in the more common case where one location_t is used by many trees, we'd
> stream less than what we stream now, due to the additional indirection.

The line_table does not store every possible location_t, only the ones that
start new maps, it should not even store one location_t per line!

But it is true that a whole file:line:column table for all locations stored in
the object file might be smaller than the line_table for the whole TU. It
depends a lot how much of the input file ends up in the object file. But I
think it should be easy to estimate the size of the line_table (see
dump_line_table_statistics). I have no idea how large a file:line:column table
would be for a typical object file. If on-disk size is a concern, one can also
replace virtual (macro) locations with spelling/expansion point locations and
not stream out any macro maps.

Moreover, when streaming out, because of how the line_table is encoded as a
contiguous array, one can mark the maps that are not used by LTO and simply not
stream them out, which may reduce the size of the line_table significantly (and
speed up any linemap merging/lookup later). This cannot be much slower than
what you are doing already, since expanding "file:line:column" requires finding
the map that holds this info. 

Of course, if you are really unlucky, each location_t used by LTO may belong to
a different map, thus you cannot remove anything and then it would have been
more efficient to use a file:line:column table. In this worst case, the
overhead would be approximately sizeof(struct line_map) * number of rows in the
file:line:column table.

Even in this worst case, my intuition says that one could re-optimize the
line_table to make it more efficient (since one location_t per map is the most
inefficient case possible) before streaming out without actually changing the
location_t values, but I would need to think a bit more whether this
re-optimization is actually possible. Perhaps Dodji can figure out a problem
with it.