https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Richard Biener from comment #2)
> > The main issue with LTO is that it re-creates a combined linemap but in
> > (most
> > of the time) quite awkward ordering (simply registering random-ordered
> > file:line:column entries by switching files/lines "appropriately").
> >
> > I've argued that it would be better to stream those file:line:columns
> > separately so we can "sort" them before handing them over to libcpp for
> > linemap re-creation.
>
> If the lines or columns are out of order, then all bets are off. Line-map
> locations have to be allocated incrementally. If you switch between files a
> lot, then you are wasting a lot of memory unnecessarily, since switching
> requires creating a new line-map.
>
> How difficult would be to track on which file you are and simply have a
> line_table per file and switch the current line_table appropriately?
>
> > So currently we do, for each "file:line:column" location we stream in:
> >
> > if (file_change)
> > {
> > if (prev_file)
> > linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> >
> > linemap_add (line_table, LC_ENTER, false, current_file, current_line);
> > }
> > else if (line_change)
> > linemap_line_start (line_table, current_line, current_col);
> >
> > return linemap_position_for_column (line_table, current_col);
> >
> > which of course puts a heavy load on the linemap encoding...
>
> According to line-map.h:
>
> /* Reason for creating a new line map with linemap_add. LC_ENTER is
> when including a new file, e.g. a #include directive in C.
> LC_LEAVE is when reaching a file's end. LC_RENAME is when a file
> name or line number changes for neither of the above reasons
> (e.g. a #line directive in C);
>
> Thus I'm not sure the above is really correct. If a single line_table is
> desirable, it probably should use LC_RENAME for different main files (as if
> they were concatenated and using #line). LC_LEAVE/LC_ENTER only makes sense
> for included files, which I presume are slightly different than concatenated
> files.
I see. An issue is that we don't keep track of whether we entered a file
already (and after re-computing line-maps we lose any "nesting" of includes,
that is, we always have enter/leave pairs). But if LC_RENAME works even
when a file was never LC_ENTERed before then we can use it.
Not sure if it will make a difference though.
Index: gcc/lto-streamer-in.c
===================================================================
--- gcc/lto-streamer-in.c (revision 221619)
+++ gcc/lto-streamer-in.c (working copy)
@@ -182,7 +182,6 @@ lto_input_location (struct bitpack_d *bp
static int current_line;
static int current_col;
bool file_change, line_change, column_change;
- bool prev_file = current_file != NULL;
if (bp_unpack_value (bp, 1))
return UNKNOWN_LOCATION;
@@ -201,12 +200,7 @@ lto_input_location (struct bitpack_d *bp
current_col = bp_unpack_var_len_unsigned (bp);
if (file_change)
- {
- if (prev_file)
- linemap_add (line_table, LC_LEAVE, false, NULL, 0);
-
- linemap_add (line_table, LC_ENTER, false, current_file, current_line);
- }
+ linemap_add (line_table, LC_RENAME, false, current_file, current_line);
else if (line_change)
linemap_line_start (line_table, current_line, current_col);
> line-map.c has code to make some erroneous cases "work": I think they should
> be replaced by linemap_assert_fails(), such that they trigger an assert when
> checking but they try to recover gracefully otherwise.
>
> How are the original locations stored on disk?
As string for file and two ints for line and column. Thus they are
stored "expanded". But they are interleaved with the trees / stmts they
are associated to.
