[Bug debug/54402] [4.8 Regression] var-tracking does not scale

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

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-30 18:24:17 UTC ---
IMHO it is really not useful to dup together completely unrelated var-tracking
PRs together.
test-tgmath.i clearly has nothing to do with frame_pointer_needed frame
replacements, or with clobber_overlapping_mems speed.
The problem there is that we have just a huge amount of VALUEs that are being
tracked, e.g. because of the huge result |= this; result |= that; result |=
someothertest;.
The reason why Alex' recent patch slows it so much down is I believe because
it doesn't check whether there aren't already debug stmts for the decls in
question, if there are at the beginning of the bb, it shouldn't try to add them
again.  Otherwise we end up with, as shown on test-tgmath2.i.*.optimized:
  # DEBUG result => result_3855
  # DEBUG result => result_3855
  # DEBUG result => result_3855
  # DEBUG result => result_3855
  # DEBUG result => result_3855
  # DEBUG result => result_3855
  # DEBUG result => result_3855
  # DEBUG result => result_3855
or
  # DEBUG result => result_3786
  # DEBUG ptype => &texpr
  # DEBUG result => result_3786
  # DEBUG ptype => &texpr
  # DEBUG result => result_3786
  # DEBUG ptype => &texpr
  # DEBUG result => result_3786
  # DEBUG ptype => &texpr
on pretty big number from the total of > 9000 basic blocks in the testcase.
So, perhaps the copying of debug stmts should start with checking if the
destination after labels contains any debug stmts, and if yes, gather their
decls into some pointer set/bitmap etc., then copy only those which don't have
debug stmts there yet (and set the pointer set/bitmap immediately too, so that
we don't copy over more than one debug stmt for each lhs decl).