[Bug middle-end/58479] [4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't see why do you think nobody would try to look at t[x][y][z] in the
debugger.
Anyway, I think we can do two things here.  Obviously we can't give up on
cunrolling it because that would be a clear -fcompare-debug failure.  But:
1) in loop unrolling, analyze the debug stmts we are about to unroll, and if
some of the debug stmts refer to a decl no other debug stmt in the loop refers
to (though would need to take into account DECL_DEBUG_EXPR overlaps) and the
expression in the debug stmt uses only SSA_NAMEs from before the loop,
constants and/or debug exprs from the loop that satisfy that recursively, just
emit the those debug stmts in the first iteration only and not repeat those in
all the other unrolled iterations
1a) alternatively to that, write some debug stmt optimization pass, that would
detect the case of useless debug stmts (saying something lives in what it is
known to live at from earlier debug stmts already)

2) have some debug stmt limits (--param controlled), above which we start
dropping debug stmts or resetting them just once or something similar.  Because
it is possible that there are multiple debug stmts per the same decl in the
loop and 1) or 1a) can't do anything.  Perhaps have the normal debug stmts in
first iteration of the unrolled loop (or a few of them, depending on how many
there are), then when we give up just reset all the debug stmts in some
iteration and after that iteration and before last iteration don't emit debug
stmts at all, then finally in the last iteration emit debug stmts again.

Testcase for 2) is e.g. -O2 -g:
int a, b, c, d, e;
int
main ()
{
  for (a = 0; a < 16; a++)
  for (b = 0; b < 16; b++)
  for (c = 0; c < 16; c++)
  for (d = 0; d < 16; d++)
  for (e = 0; e < 16; e++)
    {
      int f;
#define F10 f = 0; f = 1; f = 2; f = 3; f = 4; f = 5; f = 6; f = 7; f = 8; f =
9;
#define F100 F10 F10 F10 F10 F10 F10 F10 F10 F10 F10
      F100
    }
  return 0;
}

Another testcase, with no unrolling at all, that shows that it is easy to get
thousands of debug stmts:
int a, b, c, d, e, f;

int
main ()
{
#define F1 {{f, f, f, f, f, f, f, f, f}, {f, f, f, f, f, f, f, f, f}},
#define F10 F1 F1 F1 F1 F1 F1 F1 F1 F1 F1
#define F100 F10 F10 F10 F10 F10 F10 F10 F10 F10 F10
#define F1000 F100 F100 F100 F100 F100 F100 F100 F100 F100 F100
  int t[1000][2][9] = {
    F1000
  };
  return 0;
}

not sure where if at all to put any --param limits here though, after all, you
get for this in the initializers as huge spaghetti code and only later on that
is transformed into no actual code, just DEBUG stmt spaghetti.  Though,
supposedly this last example is already related to the PR59659 patch (which
I've done for C++ only so far).