https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #46 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Manuel, I will hopefully commit the cache patch today or tomorrow morning. It does not solve full issue. What we have is 1) we still drop columns for firefox&chromium pretty early 2) there is a bug that we sometimes output wrong line number. I think it is caused by the logic reallocating ORDINARY_MAP_NUMBER_OF_COLUMN_BITS as described in original email. It would be nice to fix those. > My guess is that the motivation here is that, if there is a large gap, it > means that we didn't get asked any source_location since a lot of lines ago. > thus it would save a lot of source_locations to simply start a new map now. > Of course, this does not work for out-of-order, but why should we pessimize > typical usage for something that should be fixed in LTO? I do not think typical usage is pesimized here. Yes, code is trying to avoid case where we skip too many location indexes because we entered lines 1...30 and now we want to insert line 1000. We do not want to fast forward by 970*80. My code keeps this logic, only it allows ordering lines backward. > > 2) (line_delta > 10 && line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > > > 1000) > > ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) is in range 7... 15, so it never > > gets high enough to make this conditional trigger. I changed it to: > > I don't understand this. A line_delta of 67 (1000/15) will already trigger it. You are right, I misread the condition. > > 4) the code deciding whether to do reuse seems worng: > > if (line_delta < 0 > > || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) > > || SOURCE_COLUMN (map, highest) >= (1U << column_bits)) > > > > line_delta really should be base_line_delta, we do not need to give up > > when map's line is 1, SOURCE_LINE (map, set->highest_line) is 5 > > and we are requested to switch to line 3. > > If you insert a line out of order without creating a new map, then > linemap_position_for_column will return the wrong value. I do not see why. If we insert first line 1 (80 columns), then we create a map 1. Now we insert line 3, we do not create new map, but we offset highest_line by 80*2. Now if we start line 2, all we need is to offset highest_line by -80 and linemap_position_for_column will still work well. Of course when we get request for column that is out of range, we need to trigger creation of new map entry. What I am missing here?