[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-04 09:21:38 UTC ---
That reduced testcase actually compiles in a few seconds on a fast box, so
let's make it larger, then it will take a few years:
struct S { unsigned long s1; void **s2[0]; };
void **a, **b, **c, **d, **e, **f;

static void **
baz (long x, long y)
{
  void **s = f;
  *f = (void **) (y << 8 | (x & 0xff));
  f += y + 1;
  return s;
}

void bar (void);
void
foo (void)
{
  void **g = b[4];
  a = b[2];
  b = b[1];
  g[2] = e;
  void **h = ((void **************************)
a)[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][66];
  void **i = ((struct S *) h)->s2[4];
  d = baz (4, 3);
  d[1] = b;
  d[2] = a;
  d[3] = bar;
  b = d;
  g[1] = i[2];
  a = g;
  ((void (*) (void)) (i[1])) ();
}

Alex, I think creating debug temporaries from within expand_debug_expr sounds
too complicated and furthermore at expand_debug_expr time we don't know yet
whether we'll actually return non-NULL for the whole expression or throw
everything away.  So, what would you think about just keeping the code as is
and just after expand_debug_expr is called, we look at the VARIABLE_LOCATION
second operand and if the RTL nesting depth is deep enough (say 3-4 levels of
nesting?) in something that we'd be ok to split into debug temporaries (I'd say
RTX_*COMPARE/UNARY/*ARITH/TERNARY plus first operand of MEM), create debug
temporary for the subexpression and replace the operand with the debug
temporary.  Otherwise, I'm afraid with TER we can end up with arbitrarily deep
DEBUG_INSN operands.