[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu

["aoliva at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #21 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I went back to r219641, just before the problem disappeared again, installed
the r220031 patch to fix the dwarf2out crash, and compilation completed
sucessfully in 36s.  Installing the patch for bug 64817 brought it down to 30s,
which is still arguably excessive, but...  we're not really doing anything
wrong here.  The huge debug loc exprs you see are the result of the compiler
looking for, and finding, an alternate representations for a variable, when a
register used in its previous location is modified.  What we have before
var-track is a sequence of groups of insns that each sets ebx to an expression
involving its prior value, and then binds a variable to it.  The chain of exprs
goes all the way back to an entry value (not in ebx), so the compiler
successfully builds more and more complex locations for the variable every time
ebx is modified, emitting a location for the variable, just to have the next
insn bind the variable to ebx.

One thing we could do to alleviate this specific scenario is to try to optimize
out the emission of a location when it's about to be modified again.  This
would address this particular issue, but it would be no help if the long chain
of exprs were to set different user variables, rather than the same.  Assuming
the program still optimizes to the same non-debug insns, as it should, we'd
have to recompute the location for each remaining user variable because it is
not rebound, and we'd end up with the same complex rtl referring all the way
back to entry-point values.

Lowering the max-vartrack-expr-depth by 1, down to 11, cuts the compile time
down to tenths of a second, so the complexity limiters we have in place are
doing their job, it's just that this rtl turns out to be particularly expensive
to handle.