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.
