The most annoying thing is the slowness of gdb and the amount of memory it uses.

I'll see to repeat an experiment from the GCC 8 times and use a LTO built
GCC for debugging in the next days.

So, configure/build GCC like

obj> CFLAGS="-g -flto" CXXFLAGS="-g -flto" /tmp/trunk/configure --disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib --disable-libstdcxx-pch
obj> make -j all-gcc CFLAGS="-g -flto" CXXFLAGS="-g -flto"

and then figure the time and memory it takes to do

obj/gcc> gdb --args ./cc1 -quiet t.c
obj/gcc> b 'value_range_base::intersect_helper'
obj/gcc> run
<breakpoint>
obj/gcc> p debug_val<TAB><TAB>

(hangs)

23609 rguenth+  20   0 2371008 2.196g 125928 R 100.0 7.008   4:06.89 gdb

otherwise debugging works fine as far as I can see, it's really just gdb
being slow and memory hungry (likely because of its internal data structures
duplicating all the sharing in the original dwarf via abstract origins and
imports).

Overhead       Samples  Command  Shared Object        Symbol                   ◆
  45.79%        202446  gdb      gdb                  [.] symbol_natural_name  ▒
  10.66%         47112  gdb      gdb                  [.] skip_ws              ▒
   7.01%         30976  gdb      gdb                  [.] iterator_next_hashed ▒
   5.32%         23530  gdb      gdb                  [.] strncmp_iw_with_mode ▒
   2.60%         11506  gdb      libc-2.26.so         [.] isspace              ▒
   2.50%         11046  gdb      gdb                  [.] completion_list_add_n

  /* Add completions for all currently loaded symbol tables.  */
  for (objfile *objfile : current_program_space->objfiles ())
    {
      for (compunit_symtab *cust : objfile->compunits ())
        add_symtab_completions (cust, tracker, mode, lookup_name,
                                sym_text, word, code);
    }

is taking up all the time.  We visit 532 compunit_symtabs.

This might be an artifact on how LTO builds CUs which has a single CU
per LTRANS unit that imports all "source CUs" (from compile-time)
that end up being used, increasing the search space considerably(?).

For symbol lookup I'd expect gdb to not use the context of the
instantiation of value_range_base::intersect_helper (the LTRANS CU)
but the CU of its abstract instance (the "source" CU).

Basically how gdb would operate when in the context of an inlined
function body though that situation probably does't reflect the LTO
one 1:1.  But think of GCC placing concrete instances in special
CUs away from their abstract and inline instances.

All that said, the TAB-completion issue makes debugging unusable
(a single completion takes a few minutes), you have to really avoid
doing this... (also seems you cannot interrupt it).