[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165

--- Comment #12 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Looking at the line maps, we have a sane list of ordinary linemaps, but then
the linemap_add call at line 4761 here:

4758    tree
4759    build_translation_unit_decl (tree name)
4760    {
4761      linemap_add (line_table, LC_ENTER, false, main_input_filename, 1);
4762      location_t loc = linemap_line_start (line_table, 1, 0);
4763      linemap_add (line_table, LC_LEAVE, false, NULL, 0);
4764      tree tu = build_decl (loc, TRANSLATION_UNIT_DECL,
4765                            name, NULL_TREE);

adds an ordinary linemap at the end:

Map #112 [0x7ffff189ce00] - LOC: 338750656 - REASON: LC_ENTER - SYSP: no
File: /home/david/coding-3/benchmarking/pb11/lin/source/aermod.f90:1
Included from: [-1] None

Hence in input.c:total_lines_num (called when input.c first access the file):

static size_t
total_lines_num (const char *file_path)
{
  size_t r = 0;
  source_location l = 0;
  if (linemap_get_file_highest_location (line_table, file_path, &l))
    {
      gcc_assert (l >= RESERVED_LOCATION_COUNT);
      expanded_location xloc = expand_location (l);
      r = xloc.line;
    }
  return r;
}

...highest location effectively is for line 1, due to that final linemap being
for line 1.

Hence c->total_lines is set to 1, and then this conditional fires within every
call to get_next_line (apart from when we read line 1):

  /* Before we update our line record, make sure the hint about the
     total number of lines of the file is correct.  If it's not, then
     we give up recording line boundaries from now on.  */
  bool update_line_record = true;
  if (c->line_num > c->total_lines)
    {
      update_line_record = false;
    }

and hence we never populate c->line record, and hence the input.c cache is
effectively turned off: every access is a cache miss.