range-cache: Fix ranger ICE if number of bbs increases [PR116899]HEADtrunkmaster

Ranger cache during initialization reserves number of basic block slots
in the m_workback vector (in an inefficient way by doing create (0)
and safe_grow_cleared (n) and truncate (0) rather than say create (n)
or reserve (n) after create).  The problem is that some passes split bbs and/or
create new basic blocks and so when one is unlucky, the quick_push into that
vector can ICE.

The following patch replaces those 4 quick_push calls with safe_push.

I've also gathered some statistics from compiling 63 gcc sources (picked those
that dependent on gimple-range-cache.h just because I had to rebuild them once
for the instrumentation), and that showed that in 81% of cases nothing has
been pushed into the vector at all (and note, not everything was small, there
were even cases with 10000+ basic blocks), another 18.5% of cases had just 1-4
elements in the vector at most, 0.08% had 5-8 and 19 out of 305386 cases
had at most 9-11 elements, nothing more.  So, IMHO reserving number of basic
block in the vector is a waste of compile time memory and with the safe_push
calls, the patch just initializes the vector to vNULL.

2024-10-01  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/116899
	* gimple-range-cache.cc (ranger_cache::ranger_cache): Set m_workback
	to vNULL instead of creating it, growing and then truncating.
	(ranger_cache::fill_block_cache): Use safe_push rather than quick_push
	on m_workback.
	(ranger_cache::range_from_dom): Likewise.

	* gcc.dg/bitint-111.c: New test.

0 files changed, 0 insertions, 0 deletions