[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #176 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-17 14:54:22 UTC ---
(In reply to comment #175)
> Created attachment 29191 [details]
> alternative patch without the compression.
> 
> This is alternative patch just skipping columns but not doing the compression.
> It seems that compression is actually quite effective.
> Non-compressing w/o column info is 1073872920 bytes,
> compression + no column is 268566544 bytes
> compression + column is 1073872920 bytes
> 
> Perhaps I messed up the caching with column info?  It strikes wrong that the
> numbers are precisely the same. But perhaps it is just reallocation strategy. I
> will also generate fresh numbers for unpatched GCC.

+    linemap_line_start (line_table, data_in->current_line, 0);

-  return linemap_position_for_column (line_table, data_in->current_col);
+  return linemap_position_for_column (line_table, 0);

linemap_line_start will aready return a location for column 0.

So I'd say we want

  if (file_change)
    {
      ...
    }

  return linemap_line_start (line_table, data_in->current_line, 0);

instead.  Which hopefully does nothing if nothing changed.

I don't know how you implement caching - you didn't attach a patch to do so.