https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> (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.
Do you mean build the line_table first in order, then when reading in the
trees/ statements, find the location_t corresponding to each given
file:line:column?
Unfortunately, there is no fast way to find the maps that correspond to a given
file:line:column.
You could collect all physical locations (file:line:columns), perhaps having
some sorted list of files that points to a sorted list of line:column pairs.
Then go through each file in order and build the line_table incrementally, once
done with a file, LC_RENAME for the next file and continue building the line
table and so on. Then, we streaming tree, find the location_t for a given
file:line:column by doing a (binary?) search in the list of maps. This last
step seems slow, not sure how it could be sped up.
> 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.
I think not much because line-map.c already has code to deal with this. Look
for:
/* So this _should_ mean we are leaving the main file --
effectively ending the compilation unit. But to_file not
being NULL means the caller thinks we are leaving to
another file. This is an erroneous behaviour but we'll
try to recover from it. Let's pretend we are not leaving
the main file. */
> > 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.
I wonder if it would not be easier to store directly the line_table and
location_t per object file, then re-encode location_t when reading to be an
index into an array of line_tables, plus the actual location_t. It just needs
to be careful to undo the re-encoding and use the correct line_table before
passing the info to the line-map functions.
