https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #16) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 > > > > --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- > > 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. > > Yep, we discussed this few times. One issue is when we sort them. > We can keep track of location as they are streamed out (and directly assign > them new IDs in the awkward ordering as they come) and then produce the > separate linemap section that would be read at once by WPA, sorted and > fed into linemaps. > > Sorting at compile time is bit tricky as we probably do not want to patch > existing pickled tree stream with the new locator IDs in the sorted sequence > and we do not really know what locations we will need ahead of time. Well, the idea was to stream another index representing the sorted order so we can sort and merge at WPA in O(n) and re-map the index on stream-in time. I don't think we want to sort at WPA time. > Other easier to implement idea for GCC 5 may be to simply collect locaiton > info and pointers to trees per SCC component andonly if it survived merging > feed it into linemap and in memory patch the new trees. This still should > save quite some memory given that most of trees read are discarded by merging > and may be quite easy to implement. > > Martin, the ICE by my patch is caused by libcpp getting out of memory? Btw, we don't have to fix this for GCC 5. We can of course backport a good solution later.
