[PR58479] introduce a param to limit debug stmts count

[Alexandre Oliva]

This bug report had various testcases that had to do with full loop
unrolling with non-automatic iterators and fixed boundaries, which
resulted in duplicating debug stmts in the loop for each iteration.  In
some cases, the resulting executable code is none, but the debug stmts
add up to millions.  Just dropping them on the floor is somewhat
undesirable, even though they're not usable for much with today's
compiler and debugger infrastructure.  I decided to introduce a param to
limit debug stmts, so that this sort of testcase doesn't run nearly
forever, eating up all memory while at that.  This is what this patchset
does.

The first patch introduces the parameter (defaulting to no limit) and
the infrastructure around it.  I decided to only detect that the limit
was exceeded and clean up existing debug stmts at pass boundaries, so
that no pass would be surprised by a failure to create a debug stmt
where it used to be possible to do so.

The second patch addresses the actual problem in some passes,
particularly in the code that copies basic blocks, used by the loop
unroller, by testing regularly whether building more debug stmts is
desirable.  They will still collect debug stmts only at the end of the
pass, since there's not much reason to rush to do that.

The third patch enables the limit by default.  I played a bit with lower
values, and on i686 and x86_64, I could build all of stage3, with all
languages enabled, without any debug info degradation, with the limit
set as low as 25000, so 1 million is a very conservative limit.
fold-const, the largest debug stmt builder, builds a total of 24382
debug stmts, and with the limit at 10000, fold_binary_loc is still the
only function that VTA disabled because the limit is reached.  At 4000,
there are only some 20 functions in the entire stage3 (host and target
libs) that get degradation.  fold-const.c:fold_comparison and
tree-browser.c:browse_tree got my attention because they built a few
hundred debug stmts more than the limit set, indicating there are other
passes that may still benefit from BUILD_DEBUG_STMTS_P testing, but I
haven't investigated any further.

Regstrapped incrementally (first patch alone, first and second, and all
3) on i686- and x86_64-linux-gnu.  Ok to install?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-max-debug-stmts-pr58479.patch
Type: text/x-diff
Size: 11384 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140315/aaa7df0f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-max-debug-stmts-opt-pr58479.patch
Type: text/x-diff
Size: 14371 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140315/aaa7df0f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-max-debug-stmts-limit-by-default-pr58479.patch
Type: text/x-diff
Size: 1399 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140315/aaa7df0f/attachment-0002.bin>
-------------- next part --------------


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist     Red Hat Brazil Toolchain Engineer