[Bug c/109695] New: crash in gimple_ranger::range_of_expr

[Bug c/109695] New: crash in gimple_ranger::range_of_expr

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

            Bug ID: 109695
           Summary: crash in gimple_ranger::range_of_expr
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54966&action=edit
gzipped C++ source code

The attached C++ code does this when compiled by today's gcc:

$ ~/gcc/results.20230502.asan.ubsan/bin/gcc -c -w bug914.cc
gcc: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
$

It was fine yesterday:

$ ~/gcc/results.20230501.asan.ubsan/bin/gcc -c -w bug914.cc
$ 

Here is a stack backtrace of the crash:

#0  0x0000000001f5328b in gimple_ranger::range_of_expr (this=0x36e4d50, r=..., 
    expr=0x7fffe0369990, stmt=0x7fffe8cd6688)
    at ../../trunk.year/gcc/gimple-range.cc:87
#1  0x0000000001f62f96 in fold_using_range::range_of_range_op (
    this=this@entry=0x7ffffc01e100, r=..., handler=..., src=...)
    at ../../trunk.year/gcc/gimple-range-fold.cc:559
#2  0x0000000001f61d4e in fold_using_range::fold_stmt (this=0x7ffffc01e100, 
    r=..., s=0x7fffe8cd6688, src=..., name=0x7fffe0369cf0)
    at ../../trunk.year/gcc/gimple-range-fold.cc:490
#3  0x0000000001f54220 in gimple_ranger::fold_range_internal (this=0x36e4d50, 
    r=..., s=0x7fffe8cd6688, name=<optimized out>)
    at ../../trunk.year/gcc/gimple-range.cc:257

[Bug c/109695] crash in gimple_ranger::range_of_expr

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at redhat dot com

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
I have a reduction running.

Git range is g:4d68c7f7b5aea5e9 .. g:1fc8da95d93d1f1f, which is 21 commits.

Given that Aldy did 13 of those 21, it looks to me to be a racing
certainty that Aldy can help here.

[Bug c/109695] crash in gimple_ranger::range_of_expr

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 54967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54967&action=edit
gzipped C++ source code

After an hour's reduction.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|13.0                        |14.0
          Component|c                           |tree-optimization
   Target Milestone|---                         |14.0
            Summary|crash in                    |[14 Regression] crash in
                   |gimple_ranger::range_of_exp |gimple_ranger::range_of_exp
                   |r                           |r

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org
           Priority|P3                          |P1
                 CC|aldyh at redhat dot com            |aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Mine.  Started with:

c92b8be9b52b7e0de5ad67bc268dad1498181908 is the first bad commit
commit c92b8be9b52b7e0de5ad67bc268dad1498181908
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Sun Feb 19 17:43:43 2023 +0100

    Convert internal representation of irange to wide_ints.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-02
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Deep recursion in the ranger is causing us to run out of stack space.  This
failure coincides with switching the internal representation of irange's to
wide_ints which take more space.

The problem happens in the waccess pass and can be seen with:
--param=ranger-debug=all

It looks like we start going bat shit crazy around:

2401           range_on_edge (_1011) on edge 1016->1017
2402             range_on_exit (_1011) from BB 1016
2403               range_of_expr(_1011) at stmt resx 4
2404                 range_on_entry (_1011) to BB 1016
2405                   range_of_stmt (_1011) at stmt _1011 = PHI <_1947(3),
_1010(1013)>

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> ---
have a look at the changes in waccess...  this compiles fine with
--disable-tree-waccess1

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I forgot to add.  Running with "ulimit -s unlimited" does not segfault.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 54973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54973&action=edit
Patch to fix the issue

The problem was exposed by the newly increased size of int_range_max.  (We may
want to address that elsewhere)   It has grown an order of magnitude in size
with wide-int

To avoid massive stack growth, range_of_stmt uses prefill_stmt_dependencies()
to do the same thing as a set of nested recursive calls to range_of_stmt, just
managing it via a stack of ssa-names instead of actual calls.

Once all the dependencies have been resolved, then we invoke fold_stmt and
evaluate the stmt, and set the result.

The problem is that while processing a series of PHIs, some ssa-names occur
multiple times, and setting the result was unconditionally done.   In this
case, it was really simple:
_1947 = 77;

_1947 was used in multiple phi arguments, as well as other stmts which then fed
long series of PHIs.  it always came up as [77, 77], but when the global value
was set again, it changes the temporal timestamp.  

The next time it was seen, it was "newer" than the previously calculated value,
and we therefore thought we had to go and prefetch things again.  It
effectively un-did much of the pre-fetching, and we'd end up with very long
call chains again. 

With the increased size of int_range_max, it blew up the stack in this
testcase.

The fix is to simply check if the new value is different than the previous
value, and not set it if so. 

This would be appropriate to put into gcc13 as well.

Patch is currently undergoing testing

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #7)
> 
> diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
> index 49e9d6b4de6..74afaaf2989 100644
> --- a/gcc/gimple-range.cc
> +++ b/gcc/gimple-range.cc
> @@ -394,7 +394,9 @@ gimple_ranger::prefill_stmt_dependencies (tree ssa)
>  	      Value_Range tmp (TREE_TYPE (name));
>  	      m_cache.get_global_range (tmp, name);
>  	      r.intersect (tmp);
> -	      m_cache.set_global_range (name, r);
> +	      // Only update the global range if it changes.
> +	      if (r != tmp)
> +		m_cache.set_global_range (name, r);
>  	    }
>  	  continue;
>  	}

Maybe the result of intersect could be used to check for changes?

if (tmp.intersect(r))
  ...

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
I've got a pretty nice reduced test-case:

$ cat pr109695.C
struct basic_string {
  basic_string(char *);
  ~basic_string();
};
struct {
  basic_string short_opt;
  basic_string long_opt;
  basic_string parameter;
  basic_string description;
} flatc_options[]{
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "",
    "", "", "", "", "", "", "", ""};

$ g++ pr109695.C -c -Wno-write-strings
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.

$ g++-13 pr109695.C -c -Wno-write-strings

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can we either stop using int_range_max in functions which can be called
recursively, or invent some better representation for int_range_max (have first
8 or 16 ranges with wide_ints inline and rest dynamically allocated when really
needed)?
Because wide_int with wide_int_storage is not meant to have compact memory
footprint (e.g. for x86 target it is 80 bytes long) and having int_range_max
have 510 of these (40800 bytes) is simply too large on stack for one variable
even if no recursion is involved.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #7)
> The problem was exposed by the newly increased size of int_range_max.  (We
> may want to address that elsewhere)   It has grown an order of magnitude in
> size with wide-int.

Yes, 10 times.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps change int_range to have the wide_ints as auto_vec with reserved space
for a few (perhaps 3 (times 2))?

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> Perhaps change int_range to have the wide_ints as auto_vec with reserved
> space for a few (perhaps 3 (times 2))?

Our original implementation was exactly that, but we switched to the current
one years ago (maybe it coincided with our switch back to trees, I can't
remember).  But yes, we're discussing options.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think even 4080 bytes for int_range_max was quite a lot.  I know it perhaps
simplifies stuff a little bit and hopefully copy construction/assignments only
copy the actual ranges and not the whole thing, but still.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Mikael Morin from comment #8)
> (In reply to Andrew Macleod from comment #7)
> > 
> > diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
> > index 49e9d6b4de6..74afaaf2989 100644
> > --- a/gcc/gimple-range.cc
> > +++ b/gcc/gimple-range.cc
> > @@ -394,7 +394,9 @@ gimple_ranger::prefill_stmt_dependencies (tree ssa)
> >  	      Value_Range tmp (TREE_TYPE (name));
> >  	      m_cache.get_global_range (tmp, name);
> >  	      r.intersect (tmp);
> > -	      m_cache.set_global_range (name, r);
> > +	      // Only update the global range if it changes.
> > +	      if (r != tmp)
> > +		m_cache.set_global_range (name, r);
> >  	    }
> >  	  continue;
> >  	}
> 
> Maybe the result of intersect could be used to check for changes?
> 
> if (tmp.intersect(r))
>   ...

Yes, my next iteration of the patch did just that..  

however, its still not quite right, theres a ripple effect with the way we
handle timestamps. the first time a name is processed, we set an "always
current" timestamp until we resolve all the dependencies and get back to it to
calculate a real value.  If the initial value and the calculated value ends up
being the same, the current fix won't clear the always-current timestamp..

still working on it.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Is there a way to measure peak memory usage in the compiler?  I'd like to
gather some stats.  Also do we have a handful of programs we typically use to
measure memory usage?  ISTR that Richard (??) had a set of memory hog programs.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For peak memory consumption there is -fmem-report, which prints stats about GC
memory.
For this PR I think you want instead measure maximum stack usage.
Perhaps GCC could be built with -fstack-usage and something could be derived
from callgraph and the stack usage info.  Or use systemtap on cc1/cc1plus and
try to determine something using it?
Or build gcc with -fsplit-stack and hook into morestack?
Or just try to check for functions with largest stack usages in cc1plus?
Doing that on the trunk gives:
objdump -dr cc1plus | grep
'>:\|sub.*0x.*[0-9a-f][0-9a-f][0-9a-f][0-9a-f],.*rsp' | awk
'/>:/{I=$2}/sub.*rsp/{J=gensub(/.*(0x[0-9a-f]+),%rsp/,"\\1","1",$0);K=strtonum(J);printf
"%d %s %s\n", K, I, $0}' | grep -v 0xffffffffffff | sort -nr
410440 <_ZN19infer_range_manager17register_all_usesEP9tree_node>:  275120d:    
48 81 ec 48 43 06 00    sub    $0x64348,%rsp
410440 <_ZN12ranger_cache21apply_inferred_rangesEP6gimple>:  274075d:   48 81
ec 48 43 06 00    sub    $0x64348,%rsp
287320
<_ZN12gori_compute15logical_combineER6vrange9tree_codeRK6irangeRKS0_S7_S7_S7_>:
 2748d0c:        48 81 ec 58 62 04 00    sub    $0x46258,%rsp
205320 <_ZN13gimple_ranger25prefill_stmt_dependenciesEP9tree_node>:  27398ed:  
48 81 ec 08 22 03 00    sub    $0x32208,%rsp
205288
<_ZN12gori_compute15condexpr_adjustER6vrangeS1_P6gimpleP9tree_nodeS5_S5_R10fur_source>:
 274c2c3:        48 81 ec e8 21 03 00    sub    $0x321e8,%rsp
204840
<_ZNK15operator_rshift9op1_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>: 
16481ba:  48 81 ec 28 20 03 00    sub    $0x32028,%rsp
164952 <_ZL21determine_value_rangeP4loopP9tree_nodeS2_P12__mpz_structS4_S4_>: 
189afc6: 48 81 ec 58 84 02 00    sub    $0x28458,%rsp
164512 <_ZN8selftestL26range_op_bitwise_and_testsEv>:  164fef4: 48 81 ec a0 82
02 00    sub    $0x282a0,%rsp
164360 <_ZN8selftestL25range_tests_int_range_maxEv>:  1a26584:  48 81 ec 08 82
02 00    sub    $0x28208,%rsp
164312 <_ZN18remove_unreachable25remove_and_update_globalsEb.part.0>:  19e1780:
48 81 ec d8 81 02 00    sub    $0x281d8,%rsp
164296 <_ZN12ranger_cache16fill_block_cacheEP9tree_nodeP15basic_block_defS3_>: 
27418ed:        48 81 ec c8 81 02 00    sub    $0x281c8,%rsp
164280
<_ZN16fold_using_range17range_of_range_opER6vrangeR23gimple_range_op_handlerR10fur_source>:
 274680a:    48 81 ec b8 81 02 00    sub    $0x281b8,%rsp
164280
<_ZN12gori_compute21compute_operand_rangeER6vrangeP6gimpleRKS0_P9tree_nodeR10fur_sourceP14value_relation.part.0>:
 274b259:      48 81 ec b8 81 02 00    sub    $0x281b8,%rsp
164248 <_ZN11range_query14get_tree_rangeER6vrangeP9tree_nodeP6gimple>: 
1a17e26:        48 81 ec 98 81 02 00    sub    $0x28198,%rsp
164232
<_ZN12gori_compute21refine_using_relationEP9tree_nodeR6vrangeS1_S3_R10fur_source15relation_kind_t>:
 274a50a:    48 81 ec 88 81 02 00    sub    $0x28188,%rsp
164104 <_ZN8selftestL21range_op_rshift_testsEv>:  1648826:      48 81 ec 08 81
02 00    sub    $0x28108,%rsp
164008
<_ZNK13operator_cast9op1_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio.part.0>:
 164e5f9:     48 81 ec a8 80 02 00    sub    $0x280a8,%rsp
163864 <_ZN21gimple_outgoing_range18calc_switch_rangesEP7gswitch>:  274335d:   
48 81 ec 18 80 02 00    sub    $0x28018,%rsp
123240
<_ZN12gori_compute22compute_operand1_rangeER6vrangeR23gimple_range_op_handlerRKS0_P9tree_nodeR10fur_sourceP14value_relation>:
 274d1de:  48 81 ec 68 e1 01 00    sub    $0x1e168,%rsp
123224
<_ZN12gori_compute22compute_operand2_rangeER6vrangeR23gimple_range_op_handlerRKS0_P9tree_nodeR10fur_sourceP14value_relation>:
 274dc8e:  48 81 ec 58 e1 01 00    sub    $0x1e158,%rsp
123176 <_ZN16path_range_query23compute_ranges_in_blockEP15basic_block_def>: 
18c708d:   48 81 ec 28 e1 01 00    sub    $0x1e128,%rsp
123176 <_ZN16fold_using_range12range_of_phiER6vrangeP4gphiR10fur_source>: 
2745820:     48 81 ec 28 e1 01 00    sub    $0x1e128,%rsp
123176 <_ZN13gimple_ranger7dump_bbEP8_IO_FILEP15basic_block_def>:  273cd4b:    
48 81 ec 28 e1 01 00    sub    $0x1e128,%rsp
123144
<_ZN16fold_using_range18range_of_cond_exprER6vrangeP7gassignR10fur_source>: 
27450a3:    48 81 ec 08 e1 01 00    sub    $0x1e108,%rsp
123128 <_ZN12ranger_cache15propagate_cacheEP9tree_node>:  2740d9d:      48 81
ec f8 e0 01 00    sub    $0x1e0f8,%rsp
83240 <_ZN8selftestL21range_op_lshift_testsEv>:  16461da:       48 81 ec 28 45
01 00    sub    $0x14528,%rsp
83048 <_ZL23adjust_op1_for_overflowR6irangeRKS_15relation_kind_tb.part.0>: 
1639c99:    48 81 ec 68 44 01 00    sub    $0x14468,%rsp
82856 <_ZL15simplify_rotateP20gimple_stmt_iterator>:  185282e:  48 81 ec a8 43
01 00    sub    $0x143a8,%rsp
82560
<_ZN21simplify_using_ranges18fold_cond_with_opsE9tree_codeP9tree_nodeS2_P6gimple>:
 1a6bfca:      48 81 ec 80 42 01 00    sub    $0x14280,%rsp
82248
<_ZL21record_nonwrapping_ivP4loopP9tree_nodeS2_P6gimpleS2_S2_bb.constprop.0>: 
189571d:   48 81 ec 48 41 01 00    sub    $0x14148,%rsp
82168
<_ZNK15operator_lshift9op1_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio.part.0>:
 1645c99:    48 81 ec f8 40 01 00    sub    $0x140f8,%rsp
82136 <_ZN13gimple_ranger11update_stmtEP6gimple>:  2738dff:     48 81 ec d8 40
01 00    sub    $0x140d8,%rsp
82136
<_ZN12ranger_cache14range_from_domER6vrangeP9tree_nodeP15basic_block_defNS_8rfd_modeE.part.0>:
 273f88d:  48 81 ec d8 40 01 00    sub    $0x140d8,%rsp
82120
<_ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>: 
163ed79:  48 81 ec c8 40 01 00    sub    $0x140c8,%rsp
82120 <_Z10range_castR6vrangeP9tree_node>:  163c1da:    48 81 ec c8 40 01 00   
sub    $0x140c8,%rsp
82104 <_ZN17block_range_cache4dumpEP8_IO_FILEP15basic_block_defb>:  273e3e9:   
48 81 ec b8 40 01 00    sub    $0x140b8,%rsp
82104 <_ZN16path_range_query16ssa_range_in_phiER6vrangeP4gphi>:  18c6573:      
48 81 ec b8 40 01 00    sub    $0x140b8,%rsp
82104
<_ZN13gimple_ranger35register_transitive_inferred_rangesEP15basic_block_def>: 
273aeba:   48 81 ec b8 40 01 00    sub    $0x140b8,%rsp
82104
<_ZN12assume_query12calculate_opEP9tree_nodeP6gimpleR6vrangeR10fur_source>: 
273b99d:     48 81 ec b8 40 01 00    sub    $0x140b8,%rsp
82104 <_Z21find_case_label_rangeP7gswitchPK6irange>:  19e2b5a:  48 81 ec b8 40
01 00    sub    $0x140b8,%rsp
82088
<_ZN15relation_oracle17validate_relationE15relation_kind_tP9tree_nodeS2_>: 
1a300c4:      48 81 ec a8 40 01 00    sub    $0x140a8,%rsp
82080
<_ZN19infer_range_manager9add_rangeEP9tree_nodeP15basic_block_defRK6vrange>: 
2750c36:    48 81 ec a0 40 01 00    sub    $0x140a0,%rsp
82080 <_ZN11range_query14query_relationEP6gimpleP9tree_nodeS3_b>:  1a189ab:    
48 81 ec a0 40 01 00    sub    $0x140a0,%rsp
81992 <_ZN18gimple_infer_range17check_assume_funcEP5gcall>:  27501ba:   48 81
ec 48 40 01 00    sub    $0x14048,%rsp
81976 <_ZN12assume_query13calculate_phiEP4gphiR6vrangeR10fur_source>:  273bdca:
48 81 ec 38 40 01 00    sub    $0x14038,%rsp
81928
<_ZNK20operator_bitwise_and9op1_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio.part.0>:
 164fad6:       48 81 ec 08 40 01 00    sub    $0x14008,%rsp
81880
<_ZL40evaluate_control_stmt_using_entry_checksP6gimpleR3vecISt4pairIP18unswitch_predicatebE7va_heap6vl_ptrEiP8hash_setIP8edge_defLb0E19default_hash_traitsISC_EE>:
 18adb2d:      48 81 ec d8 3f 01 00    sub    $0x13fd8,%rsp
43176 <_ZL25vect_recog_divmod_patternP8vec_infoP14_stmt_vec_infoPP9tree_node>: 
289acca:        48 81 ec a8 a8 00 00    sub    $0xa8a8,%rsp
42936
<_Z20range_of_var_in_loopR6vrangeP9tree_nodeP4loopP6gimpleP11range_query>: 
1a73c99:      48 81 ec b8 a7 00 00    sub    $0xa7b8,%rsp
42312 <_ZN21simplify_using_ranges8simplifyEP20gimple_stmt_iterator>:  1a7274a: 
48 81 ec 48 a5 00 00    sub    $0xa548,%rsp
42264 <_ZN12_GLOBAL__N_116pass_assumptions7executeEP8function>:  19e0da6:      
48 81 ec 18 a5 00 00    sub    $0xa518,%rsp
42248
<_ZN13back_threader20find_taken_edge_condERK3vecIP15basic_block_def7va_heap6vl_ptrEP5gcond>:
 19488c6:    48 81 ec 08 a5 00 00    sub    $0xa508,%rsp
42072 <_ZN10fur_source23register_outgoing_edgesEP5gcondR6irangeP8edge_defS5_>: 
2746196:        48 81 ec 58 a4 00 00    sub    $0xa458,%rsp
41688
<_ZNK12operator_abs9op1_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>: 
163cf10:      48 81 ec d8 a2 00 00    sub    $0xa2d8,%rsp
41640
<_ZL17value_replacementP15basic_block_defS0_P8edge_defS2_P4gphiP9tree_nodeS6_>:
 18cf2ed: 48 81 ec a8 a2 00 00    sub    $0xa2a8,%rsp
41624 <_ZL16alloca_call_typeP6gimpleb>:  277f6c6:       48 81 ec 98 a2 00 00   
sub    $0xa298,%rsp
41448 <_ZN16path_range_query24adjust_for_non_null_usesEP15basic_block_def>: 
18c7a9a:   48 81 ec e8 a1 00 00    sub    $0xa1e8,%rsp
41400 <_ZL28scev_var_range_cant_overflowP9tree_nodeS0_P4loop>:  189622d:       
48 81 ec b8 a1 00 00    sub    $0xa1b8,%rsp
41384
<_ZNK18operator_not_equal10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>:
 163cbd9:      48 81 ec a8 a1 00 00    sub    $0xa1a8,%rsp
41384
<_ZNK14operator_equal10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>: 
163c889:  48 81 ec a8 a1 00 00    sub    $0xa1a8,%rsp
41352
<_ZNK12operator_div7wi_foldER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_>:
 164b48d:      48 81 ec 88 a1 00 00    sub    $0xa188,%rsp
41328 <_Z26check_nul_terminated_arrayIP9tree_nodeEbT_S1_S1_>:  13d3f24: 48 81
ec 70 a1 00 00    sub    $0xa170,%rsp
41328 <_Z26check_nul_terminated_arrayIP6gimpleEbT_P9tree_nodeS4_>:  13d2184:   
48 81 ec 70 a1 00 00    sub    $0xa170,%rsp
41328 <_Z26check_nul_terminated_arrayIP5gcallEbT_P9tree_nodeS4_>:  13d5044:    
48 81 ec 70 a1 00 00    sub    $0xa170,%rsp
41304 <_ZN6irange6invertEv>:  1a2130a:  48 81 ec 58 a1 00 00    sub   
$0xa158,%rsp
41272
<_ZNK15operator_lshift10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>:
 1643762: 48 81 ec 38 a1 00 00    sub    $0xa138,%rsp
41272
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_>:
 163e6cd:  48 81 ec 38 a1 00 00    sub    $0xa138,%rsp
41272 <_ZN8selftest14test_expr_evalC1Ev>:  2756cda:     48 81 ec 38 a1 00 00   
sub    $0xa138,%rsp
41256 <_ZN6irange9intersectERK6vrange>:  1a2385a:       48 81 ec 28 a1 00 00   
sub    $0xa128,%rsp
41176 <_ZL33infer_loop_bounds_from_signednessP4loopP6gimple>:  1895ff2: 48 81
ec d8 a0 00 00    sub    $0xa0d8,%rsp
41160
<_ZNK14range_operator22wi_fold_in_parts_equivER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_j>:
 163a47d: 48 81 ec c8 a0 00 00    sub    $0xa0c8,%rsp
41160 <_ZN13gimple_ranger13range_of_exprER6vrangeP9tree_nodeP6gimple>: 
273c4d6:        48 81 ec c8 a0 00 00    sub    $0xa0c8,%rsp
41160
<_Z17expr_not_equal_toP9tree_nodeRK16generic_wide_intI16wide_int_storageE>: 
135839c:     48 81 ec c8 a0 00 00    sub    $0xa0c8,%rsp
41152 <_ZNK7cfn_ffs10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>: 
275489b:  48 81 ec c0 a0 00 00    sub    $0xa0c0,%rsp
41144
<_ZN18dom_opt_dom_walker40set_global_ranges_from_unreachable_edgesEP15basic_block_def>:
 184994a: 48 81 ec b8 a0 00 00    sub    $0xa0b8,%rsp
41144 <_ZN13gimple_ranger13range_of_stmtER6vrangeP6gimpleP9tree_node>: 
273a819:        48 81 ec b8 a0 00 00    sub    $0xa0b8,%rsp
41136 <_ZN12_GLOBAL__N_116memmodel_to_uhwiEP9tree_nodeP6gimplePm>:  13cc0fd:   
48 81 ec b0 a0 00 00    sub    $0xa0b0,%rsp
41112 <_ZN21simplify_using_ranges16legacy_fold_condEP5gcondPP8edge_def>: 
1a6cf03:      48 81 ec 98 a0 00 00    sub    $0xa098,%rsp
41088
<_ZN20hybrid_jt_simplifier8simplifyEP6gimpleS1_P15basic_block_defP8jt_state>: 
194c4b1:   48 81 ec 80 a0 00 00    sub    $0xa080,%rsp
41080 <_ZN16path_range_query22compute_ranges_in_phisEP15basic_block_def>: 
18c6c20:     48 81 ec 78 a0 00 00    sub    $0xa078,%rsp
41072 <_ZN15relation_oracle17validate_relationE15relation_kind_tR6vrangeS2_>: 
1a2fe8e: 48 81 ec 70 a0 00 00    sub    $0xa070,%rsp
41064 <_ZN9ssa_cache4dumpEP8_IO_FILE>:  273ed82:        48 81 ec 68 a0 00 00   
sub    $0xa068,%rsp
41064 <_ZN16fold_using_range13range_of_callER6vrangeP5gcallR10fur_source>: 
2744e8f:    48 81 ec 68 a0 00 00    sub    $0xa068,%rsp
41064 <_ZN13gimple_ranger13range_on_edgeER6vrangeP8edge_defP9tree_node>: 
273c91d:      48 81 ec 68 a0 00 00    sub    $0xa068,%rsp
41064 <_ZN12ranger_cache11resolve_domER6vrangeP9tree_nodeP15basic_block_def>: 
273f60d: 48 81 ec 68 a0 00 00    sub    $0xa068,%rsp
41064
<_ZN12gori_compute35compute_operand1_and_operand2_rangeER6vrangeR23gimple_range_op_handlerRKS0_P9tree_nodeR10fur_sourceP14value_relation>:
 274e70d:      48 81 ec 68 a0 00 00 sub    $0xa068,%rsp
41064 <_ZN12assume_query4dumpEP8_IO_FILE>:  2738a44:    48 81 ec 68 a0 00 00   
sub    $0xa068,%rsp
41064 <_ZN11range_query13value_on_edgeEP8edge_defP9tree_node>:  1a17949:       
48 81 ec 68 a0 00 00    sub    $0xa068,%rsp
41064 <_ZN11range_query13value_of_stmtEP6gimpleP9tree_node>:  1a1754f:  48 81
ec 68 a0 00 00    sub    $0xa068,%rsp
41064 <_ZN11range_query13value_of_exprEP9tree_nodeP6gimple>:  1a17759:  48 81
ec 68 a0 00 00    sub    $0xa068,%rsp
41056 <_ZL17dump_ssaname_infoP14pretty_printerP9tree_nodei.part.0>:  13c3b0d:  
48 81 ec 60 a0 00 00    sub    $0xa060,%rsp
41056 <_ZL13cprop_operandP6gimpleP17ssa_use_operand_tP11range_query>:  1848038:
48 81 ec 60 a0 00 00    sub    $0xa060,%rsp
41056 <_Z14set_range_infoP9tree_nodeRK6vrange>:  1964ca7:       48 81 ec 60 a0
00 00    sub    $0xa060,%rsp
41048 <_ZN23gimple_range_op_handler8calc_op2ER6vrangeRKS0_S3_13relation_trio>: 
2752927:        48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41048 <_ZN23gimple_range_op_handler8calc_op1ER6vrangeRKS0_S3_13relation_trio>: 
27526f7:        48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41048 <_ZN23gimple_range_op_handler8calc_op1ER6vrangeRKS0_>:  2752536:  48 81
ec 58 a0 00 00    sub    $0xa058,%rsp
41048
<_ZN19infer_range_manager18maybe_adjust_rangeER6vrangeP9tree_nodeP15basic_block_def>:
 27513c8:   48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41048 <_ZN13gimple_ranger24register_inferred_rangesEP6gimple>:  273ac9f:       
48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41048 <_ZN13gimple_ranger20export_global_rangesEv>:  273b430:   48 81 ec 58 a0
00 00    sub    $0xa058,%rsp
41048
<_ZN13gimple_ranger14range_on_entryER6vrangeP15basic_block_defP9tree_node>: 
27393bd:     48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41048 <_ZN12_GLOBAL__N_115loop_versioning21prune_loop_conditionsEP4loop>: 
272ae8a:     48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41048 <_ZN11range_query14query_relationEP8edge_defP9tree_nodeS3_b>:  1a18cfd:  
48 81 ec 58 a0 00 00    sub    $0xa058,%rsp
41040 <_ZN16ssa_block_ranges4dumpEP8_IO_FILE>:  273dc1a:        48 81 ec 50 a0
00 00    sub    $0xa050,%rsp
41040
<_ZN16path_range_query22internal_range_of_exprER6vrangeP9tree_nodeP6gimple>: 
18c6e0b:    48 81 ec 50 a0 00 00    sub    $0xa050,%rsp
41040
<_ZN12ranger_cache23register_inferred_valueERK6vrangeP9tree_nodeP15basic_block_def>:
 274056b:    48 81 ec 50 a0 00 00    sub    $0xa050,%rsp
41040
<_ZN12ranger_cache10edge_rangeER6vrangeP8edge_defP9tree_nodeNS_8rfd_modeE>: 
2740274:     48 81 ec 50 a0 00 00    sub    $0xa050,%rsp
41040 <_Z29duplicate_ssa_name_range_infoP9tree_nodeS0_>:  1965057:      48 81
ec 50 a0 00 00    sub    $0xa050,%rsp
41040 <_Z17debug_seed_rangerR13gimple_ranger>:  27566fb:        48 81 ec 50 a0
00 00    sub    $0xa050,%rsp
41032
<_ZNK13operator_cast10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>: 
16512bd:   48 81 ec 48 a0 00 00    sub    $0xa048,%rsp
41032
<_ZN13back_threader22find_taken_edge_switchERK3vecIP15basic_block_def7va_heap6vl_ptrEP7gswitch>:
 19487bc:        48 81 ec 48 a0 00 00    sub    $0xa048,%rsp
40968
<_ZN12gori_compute21outgoing_edge_range_pER6vrangeP8edge_defP9tree_nodeR11range_query>:
 274f5a0: 48 81 ec 08 a0 00 00    sub    $0xa008,%rsp
40936 <_ZN21simplify_using_ranges9fold_condEP5gcond>:  1a6e521: 48 81 ec e8 9f
00 00    sub    $0x9fe8,%rsp
40920
<_ZNK15operator_rshift10fold_rangeER6irangeP9tree_nodeRKS0_S5_13relation_trio>:
 1643682: 48 81 ec d8 9f 00 00    sub    $0x9fd8,%rsp
40920 <_ZNK14irange_storage7equal_pERK6irangeP9tree_node>:  1a2eb89:    48 81
ec d8 9f 00 00    sub    $0x9fd8,%rsp
40920 <_ZN11Value_RangeaSERK6vrange.isra.0>:  2750095:  48 81 ec d8 9f 00 00   
sub    $0x9fd8,%rsp
40920 <_Z16get_nonzero_bitsPK9tree_node.part.0>:  1963f15:      48 81 ec d8 9f
00 00    sub    $0x9fd8,%rsp
40912 <_ZN14irange_storage10set_irangeERK6irange.part.0>:  1a2e60a:     48 81
ec d0 9f 00 00    sub    $0x9fd0,%rsp
38872 <_ZN3ana8selftestL17test_sm_state_mapEv>:  1ae38cf:       48 81 ec d8 97
00 00    sub    $0x97d8,%rsp
21384 <_ZN3ana17impl_run_checkersEPNS_6loggerE>:  1acd577:      48 81 ec 88 53
00 00    sub    $0x5388,%rsp
20216 <_ZN3ana8selftestL16test_iteration_1Ev>:  1afbcac:        48 81 ec f8 4e
00 00    sub    $0x4ef8,%rsp
19752 <_ZN3ana8selftestL18test_state_mergingEv>:  1afca8f:      48 81 ec 28 4d
00 00    sub    $0x4d28,%rsp
19640 <_ZN3ana8selftestL23test_constraint_mergingEv>:  1afb84c: 48 81 ec b8 4c
00 00    sub    $0x4cb8,%rsp
19640 <_ZN3ana8selftestL19test_many_constantsEv>:  28eeb44:     48 81 ec b8 4c
00 00    sub    $0x4cb8,%rsp
19608 <_ZN3ana8selftestL26test_program_state_mergingEv>:  1ae4ecf:      48 81
ec 98 4c 00 00    sub    $0x4c98,%rsp
19584 <_ZN3ana8selftestL15test_equality_1Ev>:  1af6f09: 48 81 ec 80 4c 00 00   
sub    $0x4c80,%rsp
19584 <_ZN3ana8selftestL13test_equalityEv>:  28f14cd:   48 81 ec 80 4c 00 00   
sub    $0x4c80,%rsp
19480 <_ZN3ana8selftestL25test_binop_svalue_foldingEv>:  1af3d8e:       48 81
ec 18 4c 00 00    sub    $0x4c18,%rsp
19464 <_ZN3ana8selftestL28test_program_state_merging_2Ev>:  1ae3470:    48 81
ec 08 4c 00 00    sub    $0x4c08,%rsp
19448 <_ZN3ana8selftestL23test_canonicalization_3Ev>:  1af9fdb: 48 81 ec f8 4b
00 00    sub    $0x4bf8,%rsp
19440 <_ZN3ana8selftestL23test_canonicalization_2Ev>:  1af87dd: 48 81 ec f0 4b
00 00    sub    $0x4bf0,%rsp
19432 <_ZN3ana8selftestL32test_get_representative_path_varEv>:  1af96c1:       
48 81 ec e8 4b 00 00    sub    $0x4be8,%rsp
19400 <_ZN3ana8selftestL17test_stack_framesEv>:  1b007bf:       48 81 ec c8 4b
00 00    sub    $0x4bc8,%rsp
19400 <_ZN3ana8selftestL12test_array_2Ev>:  1af78d1:    48 81 ec c8 4b 00 00   
sub    $0x4bc8,%rsp
19392 <_ZN3ana8selftestL11test_structEv>:  1af6b08:     48 81 ec c0 4b 00 00   
sub    $0x4bc0,%rsp
19376 <_ZN3ana8selftestL28test_get_representative_treeEv>:  1b021d6:    48 81
ec b0 4b 00 00    sub    $0x4bb0,%rsp
19352 <_ZN3ana8selftestL24test_compound_assignmentEv>:  1af84ca:        48 81
ec 98 4b 00 00    sub    $0x4b98,%rsp
19344 <_ZN3ana8selftestL8test_varEv>:  1af742d: 48 81 ec 90 4b 00 00    sub   
$0x4b90,%rsp
19344 <_ZN3ana8selftestL23test_sub_svalue_foldingEv>:  1af1fc4: 48 81 ec 90 4b
00 00    sub    $0x4b90,%rsp
19336 <_ZN3ana8selftestL25test_constant_comparisonsEv>:  28ec11f:       48 81
ec 88 4b 00 00    sub    $0x4b88,%rsp
19328 <_ZN3ana8selftestL11test_allocaEv>:  1b0168f:     48 81 ec 80 4b 00 00   
sub    $0x4b80,%rsp
19320 <_ZN3ana8selftestL15test_involves_pEv>:  1af33e8: 48 81 ec 78 4b 00 00   
sub    $0x4b78,%rsp
19320 <_ZN3ana8selftestL11test_mallocEv>:  1afae06:     48 81 ec 78 4b 00 00   
sub    $0x4b78,%rsp
19312 <_ZN3ana8selftestL27test_unaryop_svalue_foldingEv>:  1af3006:     48 81
ec 70 4b 00 00    sub    $0x4b70,%rsp
19312 <_ZN3ana8selftestL27test_initial_svalue_foldingEv>:  1af28c6:     48 81
ec 70 4b 00 00    sub    $0x4b70,%rsp
19312 <_ZN3ana8selftestL21test_unique_constantsEv>:  1af3716:   48 81 ec 70 4b
00 00    sub    $0x4b70,%rsp
19304 <_ZN3ana8selftestL9test_dumpEv>:  1b020a0:        48 81 ec 68 4b 00 00   
sub    $0x4b68,%rsp
19304 <_ZN3ana8selftestL9test_bitsEv>:  28eb80c:        48 81 ec 68 4b 00 00   
sub    $0x4b68,%rsp
19304 <_ZN3ana8selftestL35test_POINTER_PLUS_EXPR_then_MEM_REFEv>:  1af8382:    
48 81 ec 68 4b 00 00    sub    $0x4b68,%rsp
19304 <_ZN3ana8selftestL23test_malloc_constraintsEv>:  1afaaa8: 48 81 ec 68 4b
00 00    sub    $0x4b68,%rsp
19304 <_ZN3ana8selftestL20test_constraint_implEv>:  28eae5f:    48 81 ec 68 4b
00 00    sub    $0x4b68,%rsp
19304 <_ZN3ana8selftestL17test_transitivityEv>:  28e997b:       48 81 ec 68 4b
00 00    sub    $0x4b68,%rsp
19304 <_ZN3ana8selftestL15test_assignmentEv>:  1afa198: 48 81 ec 68 4b 00 00   
sub    $0x4b68,%rsp
19296 <_ZN3ana8selftestL26test_constraint_conditionsEv>:  28f64cd:      48 81
ec 60 4b 00 00    sub    $0x4b60,%rsp
19296 <_ZN3ana8selftestL12test_purgingEv>:  28ed806:    48 81 ec 60 4b 00 00   
sub    $0x4b60,%rsp
19296 <_ZN3ana8selftestL12test_mem_refEv>:  1af822d:    48 81 ec 60 4b 00 00   
sub    $0x4b60,%rsp
19280 <_ZN3ana8selftestL23test_canonicalization_4Ev>:  1af2624: 48 81 ec 50 4b
00 00    sub    $0x4b50,%rsp
19264 <_ZN3ana8selftestL12test_array_1Ev>:  1af6e38:    48 81 ec 40 4b 00 00   
sub    $0x4b40,%rsp
19256 <_ZN3ana8selftestL20test_program_state_1Ev>:  1ae4ccb:    48 81 ec 38 4b
00 00    sub    $0x4b38,%rsp
19232 <_ZN3ana8selftestL22test_bit_range_regionsEv>:  1aec219:  48 81 ec 20 4b
00 00    sub    $0x4b20,%rsp
19216 <_ZN3ana8selftestL20test_program_state_2Ev>:  1ae0529:    48 81 ec 10 4b
00 00    sub    $0x4b10,%rsp
19184 <_ZN3ana8selftestL25test_widening_constraintsEv>:  1aed7ea:       48 81
ec f0 4a 00 00    sub    $0x4af0,%rsp
19160 <_ZN3ana8selftestL27test_program_point_equalityEv>:  1add8e0:     48 81
ec d8 4a 00 00    sub    $0x4ad8,%rsp
19160 <_ZN3ana8selftestL20test_unique_unknownsEv>:  1aeb9c4:    48 81 ec d8 4a
00 00    sub    $0x4ad8,%rsp
19152 <_ZN3ana8selftestL31test_bits_within_svalue_foldingEv>:  1aec408: 48 81
ec d0 4a 00 00    sub    $0x4ad0,%rsp
19152 <_ZN3ana8selftestL20test_descendent_of_pEv>:  1aebb03:    48 81 ec d0 4a
00 00    sub    $0x4ad0,%rsp
16616 <_ZL22estimate_local_effectsP11cgraph_node>:  27c5aaa:    48 81 ec e8 40
00 00    sub    $0x40e8,%rsp
16328 <_Z35ipa_merge_fn_summary_after_inliningP11cgraph_edge>:  146ae10:       
48 81 ec c8 3f 00 00    sub    $0x3fc8,%rsp
16296 <_ZL27decide_whether_version_nodeP11cgraph_node>:  27cde7d:       48 81
ec a8 3f 00 00    sub    $0x3fa8,%rsp
16280 <_ZN16ipa_fn_summary_t9duplicateEP11cgraph_nodeS1_P14ipa_fn_summaryS3_>: 
146eac6:        48 81 ec 98 3f 00 00    sub    $0x3f98,%rsp
16104 <_Z21do_estimate_edge_timeP11cgraph_edgeP5sreal>:  147d7b7:       48 81
ec e8 3e 00 00    sub    $0x3ee8,%rsp
16072 <_Z22do_estimate_edge_hintsP11cgraph_edge>:  147e625:     48 81 ec c8 3e
00 00    sub    $0x3ec8,%rsp
16072 <_Z21do_estimate_edge_sizeP11cgraph_edge.part.0>:  147cc65:       48 81
ec c8 3e 00 00    sub    $0x3ec8,%rsp
12152 <_Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb>:  1480600:
48 81 ec 78 2f 00 00    sub    $0x2f78,%rsp
12088 <_Z29ix86_valid_target_attribute_pP9tree_nodeS0_S0_i>:  1b6919d:  48 81
ec 38 2f 00 00    sub    $0x2f38,%rsp
8568 <_ZL33gimple_fold_builtin_clear_paddingP20gimple_stmt_iterator>:  13aee2d:
48 81 ec 78 21 00 00    sub    $0x2178,%rsp
8544 <_ZL19clear_padding_unionP20clear_padding_structP9tree_nodelb>:  13aed58: 
48 81 ec 60 21 00 00    sub    $0x2160,%rsp
8536 <_Z26clear_type_padding_in_maskP9tree_nodePh>:  13af2cc:   48 81 ec 58 21
00 00    sub    $0x2158,%rsp
6088 <_Z32ix86_valid_target_attribute_treeP9tree_nodeS0_P11gcc_optionsS2_b>: 
1b68eb1:  48 81 ec c8 17 00 00    sub    $0x17c8,%rsp
5912 <_ZL28determine_group_iv_cost_condP11ivopts_dataP8iv_groupP7iv_cand>: 
188613a:    48 81 ec 18 17 00 00    sub    $0x1718,%rsp
5448 <_ZN8selftestL16range_tests_miscEv>:  1a28014:     48 81 ec 48 15 00 00   
sub    $0x1548,%rsp
4936 <_ZL18cselib_record_setsP8rtx_insn>:  124b6dd:     48 81 ec 48 13 00 00   
sub    $0x1348,%rsp
4576 <_ZN8selftestL19range_tests_irange3Ev>:  1a25261:  48 81 ec e0 11 00 00   
sub    $0x11e0,%rsp
4360 <md5_stream>:  29e8d86:    48 81 ec 08 11 00 00    sub    $0x1108,%rsp
4168 <_Z14gt_pch_restoreP8_IO_FILE>:  1398d13:  48 81 ec 48 10 00 00    sub   
$0x1048,%rsp
4120 <_ZN8selftest9read_fileERKNS_8locationEPKc>:  2951eba:     48 81 ec 18 10
00 00    sub    $0x1018,%rsp
4120 <_ZL23verify_speculative_callP11cgraph_nodeP6gimplejP11cgraph_edge>: 
122add2:     48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4096 <_ZNK9vec_usage4dumpEP12mem_locationR9mem_usage>:  294f90e:        48 81
ec 00 10 00 00    sub    $0x1000,%rsp
4096 <lrealpath>:  29ef6f8:     48 81 ec 00 10 00 00    sub    $0x1000,%rsp
That is just insane.  selftests I assume aren't called recursively, but 410k
stack in one function?
Compare that to gcc 12 (April 18th build):
objdump -dr cc1plus | grep
'>:\|sub.*0x.*[0-9a-f][0-9a-f][0-9a-f][0-9a-f],.*rsp' | awk
'/>:/{I=$2}/sub.*rsp/{J=gensub(/.*(0x[0-9a-f]+),%rsp/,"\\1","1",$0);K=strtonum(J);printf
"%d %s %s\n", K, I, $0}' | grep -v 0xffffffffffff | sort -nr
20536
<_ZN12gori_compute15condexpr_adjustER6irangeS1_P6gimpleP9tree_nodeS5_S5_R10fur_source>:
 2622776: 48 81 ec 38 50 00 00    sub    $0x5038,%rsp
20504 <_ZNK15operator_rshift9op1_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>: 
2735799:        48 81 ec 18 50 00 00    sub    $0x5018,%rsp
16744 <_ZNK13operator_cast9op1_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>: 
2728476:  48 81 ec 68 41 00 00    sub    $0x4168,%rsp
16448 <_ZN8selftestL25range_tests_int_range_maxEv>:  1997a7d:   48 81 ec 40 40
00 00    sub    $0x4040,%rsp
16440 <_ZN8selftestL26range_op_bitwise_and_testsEv>:  272a18a:  48 81 ec 38 40
00 00    sub    $0x4038,%rsp
16440
<_ZN12gori_compute21compute_operand_rangeER6irangeP6gimpleRKS0_P9tree_nodeR10fur_source>:
 262168a:       48 81 ec 38 40 00 00    sub    $0x4038,%rsp
16416 <_ZN8selftestL21range_op_rshift_testsEv>:  2735b68:       48 81 ec 20 40
00 00    sub    $0x4020,%rsp
12528 <_ZN8selftestL18range_tests_legacyEv>:  1997f55:  48 81 ec f0 30 00 00   
sub    $0x30f0,%rsp
12360 <_ZN21gimple_outgoing_range18calc_switch_rangesEP7gswitch>:  261940a:    
48 81 ec 48 30 00 00    sub    $0x3048,%rsp
12328 <_ZN12gori_compute15logical_combineER6irange9tree_codeRKS0_S4_S4_S4_S4_>:
 2620078:       48 81 ec 28 30 00 00    sub    $0x3028,%rsp
12312
<_ZN16fold_using_range18range_of_cond_exprER6irangeP7gassignR10fur_source>: 
261b780:     48 81 ec 18 30 00 00    sub    $0x3018,%rsp
12312 <_ZN12ranger_cache16fill_block_cacheEP9tree_nodeP15basic_block_defS3_>: 
26182ca: 48 81 ec 18 30 00 00    sub    $0x3018,%rsp
12312 <_ZN12ranger_cache15propagate_cacheEP9tree_node>:  2617960:       48 81
ec 18 30 00 00    sub    $0x3018,%rsp
12296 <_ZN11range_query14get_tree_rangeER6irangeP9tree_nodeP6gimple>:  198eee6:
48 81 ec 08 30 00 00    sub    $0x3008,%rsp
11768 <_Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb>:  1420ff0:
48 81 ec f8 2d 00 00    sub    $0x2df8,%rsp
11704 <_Z29ix86_valid_target_attribute_pP9tree_nodeS0_S0_i>:  1abd69d:  48 81
ec b8 2d 00 00    sub    $0x2db8,%rsp
8744 <_ZL15simplify_rotateP20gimple_stmt_iterator>:  17d683e:   48 81 ec 28 22
00 00    sub    $0x2228,%rsp
8568 <_ZL33gimple_fold_builtin_clear_paddingP20gimple_stmt_iterator>:  13525dd:
48 81 ec 78 21 00 00    sub    $0x2178,%rsp
8544 <_ZL19clear_padding_unionP20clear_padding_structP9tree_nodelb>:  1352510: 
48 81 ec 60 21 00 00    sub    $0x2160,%rsp
8536 <_ZNK15operator_lshift9op1_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>: 
272d8b9: 48 81 ec 58 21 00 00    sub    $0x2158,%rsp
8536 <_Z26clear_type_padding_in_maskP9tree_nodePh>:  1352a4c:   48 81 ec 58 21
00 00    sub    $0x2158,%rsp
8424 <_ZN16fold_using_range17range_of_range_opER6irangeP6gimpleR10fur_source>: 
261cac3:        48 81 ec e8 20 00 00    sub    $0x20e8,%rsp
8392 <_ZN8selftestL21range_op_lshift_testsEv>:  272ddef:        48 81 ec c8 20
00 00    sub    $0x20c8,%rsp
8296
<_ZNK20operator_bitwise_and9op1_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code.part.0>:
 2728c86:     48 81 ec 68 20 00 00    sub    $0x2068,%rsp
8264 <_ZN16fold_using_range12range_of_phiER6irangeP4gphiR10fur_source>: 
261be26:       48 81 ec 48 20 00 00    sub    $0x2048,%rsp
8264 <_Z10fold_rangeR6irangeP6gimpleS0_S0_>:  261f7ce:  48 81 ec 48 20 00 00   
sub    $0x2048,%rsp
8264 <_Z10fold_rangeR6irangeP6gimpleS0_>:  261f78b:     48 81 ec 48 20 00 00   
sub    $0x2048,%rsp
8264 <_Z10fold_rangeR6irangeP6gimplejPS_>:  261f810:    48 81 ec 48 20 00 00   
sub    $0x2048,%rsp
8248 <_ZN13gimple_ranger25prefill_stmt_dependenciesEP9tree_node>:  26125bd:    
48 81 ec 38 20 00 00    sub    $0x2038,%rsp
8232 <_ZN16path_range_query23compute_ranges_in_blockEP15basic_block_def>: 
184174d:     48 81 ec 28 20 00 00    sub    $0x2028,%rsp
8232
<_ZN12gori_compute22compute_operand2_rangeER6irangeP6gimpleRKS0_P9tree_nodeR10fur_source>:
 26222a6:       48 81 ec 28 20 00 00    sub    $0x2028,%rsp
8232
<_ZN12gori_compute22compute_operand1_rangeER6irangeP6gimpleRKS0_P9tree_nodeR10fur_source>:
 2621ea6:       48 81 ec 28 20 00 00    sub    $0x2028,%rsp
8232 <_Z21find_case_label_rangeP7gswitchPK6irange>:  195363a:   48 81 ec 28 20
00 00    sub    $0x2028,%rsp
8224 <_ZN13gimple_ranger20export_global_rangesEv>:  2613048:    48 81 ec 20 20
00 00    sub    $0x2020,%rsp
8216 <_ZN13gimple_ranger7dump_bbEP8_IO_FILEP15basic_block_def>:  2613a06:      
48 81 ec 18 20 00 00    sub    $0x2018,%rsp
8200
<_ZN16fold_using_range27range_of_builtin_ubsan_callER6irangeP5gcall9tree_codeR10fur_source>:
 261b55d:     48 81 ec 08 20 00 00    sub    $0x2008,%rsp
6360 <_ZL28determine_group_iv_cost_condP11ivopts_dataP8iv_groupP7iv_cand>: 
18050ba:    48 81 ec d8 18 00 00    sub    $0x18d8,%rsp
5896 <_Z32ix86_valid_target_attribute_treeP9tree_nodeS0_P11gcc_optionsS2_b>: 
1abd3b1:  48 81 ec 08 17 00 00    sub    $0x1708,%rsp
5272 <_ZN21simplify_using_ranges8simplifyEP20gimple_stmt_iterator>:  19e126a:  
48 81 ec 98 14 00 00    sub    $0x1498,%rsp
4952 <_ZL18cselib_record_setsP8rtx_insn>:  11e5d0d:     48 81 ec 58 13 00 00   
sub    $0x1358,%rsp
4616 <_ZN6irange6invertEv>:  1992bfd:   48 81 ec 08 12 00 00    sub   
$0x1208,%rsp
4536 <_ZNK14range_operator10fold_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>: 
27297ba:        48 81 ec b8 11 00 00    sub    $0x11b8,%rsp
4536
<_ZNK12operator_div7wi_foldER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_>:
 2730f7d:       48 81 ec b8 11 00 00    sub    $0x11b8,%rsp
4520
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_>:
 27290fd:   48 81 ec a8 11 00 00    sub    $0x11a8,%rsp
4472
<_ZNK12operator_abs9op1_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code.part.0>: 
2727c9d:     48 81 ec 78 11 00 00    sub    $0x1178,%rsp
4456 <_ZNK20operator_bitwise_and24remove_impossible_rangesER6irangeRKS0_>: 
272b673:    48 81 ec 68 11 00 00    sub    $0x1168,%rsp
4360 <md5_stream>:  28b87e6:    48 81 ec 08 11 00 00    sub    $0x1108,%rsp
4344
<_ZNK18operator_not_equal10fold_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code.part.0>:
 2726e52:     48 81 ec f8 10 00 00    sub    $0x10f8,%rsp
4344
<_ZNK14operator_equal10fold_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code.part.0>:
 2726b22: 48 81 ec f8 10 00 00    sub    $0x10f8,%rsp
4344 <_ZL16alloca_call_typeP6gimpleb>:  2650686:        48 81 ec f8 10 00 00   
sub    $0x10f8,%rsp
4344
<_Z17expr_not_equal_toP9tree_nodeRK16generic_wide_intI16wide_int_storageE>: 
12fafec:      48 81 ec f8 10 00 00    sub    $0x10f8,%rsp
4264 <_ZN6irange16irange_intersectERKS_>:  199625a:     48 81 ec a8 10 00 00   
sub    $0x10a8,%rsp
4264 <_ZN10fur_source23register_outgoing_edgesEP5gcondR6irangeP8edge_defS5_>: 
261c4a6: 48 81 ec a8 10 00 00    sub    $0x10a8,%rsp
4232 <_ZNK15operator_lshift10fold_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>:
 2729cdd:       48 81 ec 88 10 00 00    sub    $0x1088,%rsp
4216
<_ZN13back_threader20find_taken_edge_condERK3vecIP15basic_block_def7va_heap6vl_ptrEP5gcond>:
 18c3b8f:     48 81 ec 78 10 00 00    sub    $0x1078,%rsp
4216 <_ZN12ranger_cache13range_on_edgeER6irangeP8edge_defP9tree_node.part.0>: 
2616a16: 48 81 ec 78 10 00 00    sub    $0x1078,%rsp
4200 <_ZN13gimple_ranger13range_of_exprER6irangeP9tree_nodeP6gimple>:  26133b6:
48 81 ec 68 10 00 00    sub    $0x1068,%rsp
4184 <_ZN13gimple_ranger13range_of_stmtER6irangeP6gimpleP9tree_node>:  2612ced:
48 81 ec 58 10 00 00    sub    $0x1058,%rsp
4184 <_ZN12_GLOBAL__N_115loop_versioning21prune_loop_conditionsEP4loop>: 
2603a4a:      48 81 ec 58 10 00 00    sub    $0x1058,%rsp
4176 <_ZN8selftest14test_expr_evalC1Ev>:  2624e77:      48 81 ec 50 10 00 00   
sub    $0x1050,%rsp
4168 <_ZN3ana8selftestL17test_sm_state_mapEv>:  1a4d99f:        48 81 ec 48 10
00 00    sub    $0x1048,%rsp
4168 <_ZN16path_range_query22compute_ranges_in_phisEP15basic_block_def>: 
1841614:      48 81 ec 48 10 00 00    sub    $0x1048,%rsp
4168 <_Z14gt_pch_restoreP8_IO_FILE>:  133c2b3:  48 81 ec 48 10 00 00    sub   
$0x1048,%rsp
4152 <_ZNK15operator_rshift10fold_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>:
 2729fad:       48 81 ec 38 10 00 00    sub    $0x1038,%rsp
4152 <_ZN16path_range_query24adjust_for_non_null_usesEP15basic_block_def>: 
1840b6a:    48 81 ec 38 10 00 00    sub    $0x1038,%rsp
4152
<_ZN12gori_compute21outgoing_edge_range_pER6irangeP8edge_defP9tree_nodeR11range_query>:
 2623c90:  48 81 ec 38 10 00 00    sub    $0x1038,%rsp
4136
<_ZN12ranger_cache14range_from_domER6irangeP9tree_nodeP15basic_block_def.part.0>:
 2615dad:        48 81 ec 28 10 00 00    sub    $0x1028,%rsp
4136 <_ZN11range_query15get_value_rangeEPK9tree_nodeP6gimple>:  198f5ae:       
48 81 ec 28 10 00 00    sub    $0x1028,%rsp
4136 <_Z10range_castR6irangeP9tree_node>:  2723b7f:     48 81 ec 28 10 00 00   
sub    $0x1028,%rsp
4120 <_ZNK13operator_cast10fold_rangeER6irangeP9tree_nodeRKS0_S5_9tree_code>: 
273423d: 48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZN8selftest9read_fileERKNS_8locationEPKc>:  282e24a:     48 81 ec 18 10
00 00    sub    $0x1018,%rsp
4120 <_ZN21simplify_using_ranges9fold_condEP5gcond>:  19dca01:  48 81 ec 18 10
00 00    sub    $0x1018,%rsp
4120
<_ZN20hybrid_jt_simplifier8simplifyEP6gimpleS1_P15basic_block_defP8jt_state>: 
18c792b:    48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZN17block_range_cache4dumpEP8_IO_FILEP15basic_block_defb>:  261585a:    
48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZN16path_range_query19range_on_path_entryER6irangeP9tree_node>: 
183fcd6:        48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZN16path_range_query16ssa_range_in_phiER6irangeP4gphi>:  1840e2a:       
48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120
<_ZN13gimple_ranger14range_on_entryER6irangeP15basic_block_defP9tree_node>: 
261213a:      48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZN13gimple_ranger13range_on_edgeER6irangeP8edge_defP9tree_node>: 
26136c0:       48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120
<_ZN12gori_compute35compute_operand1_and_operand2_rangeER6irangeP6gimpleRKS0_P9tree_nodeR10fur_source>:
 26226cc:  48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZN11range_query13value_of_exprEP9tree_nodeP6gimple>:  198e565:   48 81
ec 18 10 00 00    sub    $0x1018,%rsp
4120 <_ZL23verify_speculative_callP11cgraph_nodeP6gimplejP11cgraph_edge>: 
11c5d23:     48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4112 <_ZN11range_query13value_on_edgeEP8edge_defP9tree_node>:  198e727: 48 81
ec 10 10 00 00    sub    $0x1010,%rsp
4112 <_ZN11range_query13value_of_stmtEP6gimpleP9tree_node>:  198e63d:   48 81
ec 10 10 00 00    sub    $0x1010,%rsp
4104 <_ZN16ssa_global_cache4dumpEP8_IO_FILE>:  261637a: 48 81 ec 08 10 00 00   
sub    $0x1008,%rsp
4104 <_ZN12ranger_cache17update_to_nonnullEP15basic_block_defP9tree_node>: 
26170c9:    48 81 ec 08 10 00 00    sub    $0x1008,%rsp
4104 <_ZN11range_query14query_relationEP8edge_defP9tree_nodeS3_b>:  198f45d:   
48 81 ec 08 10 00 00    sub    $0x1008,%rsp
4104 <_ZN11range_query14query_relationEP6gimpleP9tree_nodeS3_b>:  198f399:     
48 81 ec 08 10 00 00    sub    $0x1008,%rsp
4096 <_ZNK9vec_usage4dumpEP12mem_locationR9mem_usage>:  282c08e:        48 81
ec 00 10 00 00    sub    $0x1000,%rsp
4096 <_ZN8fur_listC1ER6irangeS1_>:  261aa03:    48 81 ec 00 10 00 00    sub   
$0x1000,%rsp
4096 <_ZN8fur_listC1ER6irange>:  261a936:       48 81 ec 00 10 00 00    sub   
$0x1000,%rsp
4096 <_ZN16ssa_block_ranges4dumpEP8_IO_FILE>:  2614c84: 48 81 ec 00 10 00 00   
sub    $0x1000,%rsp
4096
<_ZN13back_threader22find_taken_edge_switchERK3vecIP15basic_block_def7va_heap6vl_ptrEP7gswitch>:
 18c3a6a: 48 81 ec 00 10 00 00    sub    $0x1000,%rsp
4096 <_Z17debug_seed_rangerR13gimple_ranger>:  2624aa7: 48 81 ec 00 10 00 00   
sub    $0x1000,%rsp
4096 <lrealpath>:  28bf1f8:     48 81 ec 00 10 00 00    sub    $0x1000,%rsp

Even there ranger occupies the highest spots due to int_range_max.
Compare to GCC 10:
objdump -dr cc1plus | grep
'>:\|sub.*0x.*[0-9a-f][0-9a-f][0-9a-f][0-9a-f],.*rsp' | awk
'/>:/{I=$2}/sub.*rsp/{J=gensub(/.*(0x[0-9a-f]+),%rsp/,"\\1","1",$0);K=strtonum(J);printf
"%d %s %s\n", K, I, $0}' | grep -v 0xffffffffffff | sort -nr
5384 <_Z32ix86_valid_target_attribute_treeP9tree_nodeS0_P11gcc_optionsS2_b>: 
1634edd:  48 81 ec 08 15 00 00    sub    $0x1508,%rsp
5384 <_Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb>:  1054730: 
48 81 ec 08 15 00 00    sub    $0x1508,%rsp
5336 <_Z29ix86_valid_target_attribute_pP9tree_nodeS0_S0_i>:  163519d:   48 81
ec d8 14 00 00    sub    $0x14d8,%rsp
4952 <_ZL18cselib_record_setsP8rtx_insn>:   e1a65d:     48 81 ec 58 13 00 00   
sub    $0x1358,%rsp
4360 <md5_stream>:  1e4a72f:    48 81 ec 08 11 00 00    sub    $0x1108,%rsp
4120 <_ZN8selftest9read_fileERKNS_8locationEPKc>:  1dd05da:     48 81 ec 18 10
00 00    sub    $0x1018,%rsp
4120 <_ZL23verify_speculative_callP11cgraph_nodeP6gimplejP11cgraph_edge>:  
df91d2:     48 81 ec 18 10 00 00    sub    $0x1018,%rsp
4096 <_ZNK9vec_usage4dumpEP12mem_locationR9mem_usage>:  1dce49e:        48 81
ec 00 10 00 00    sub    $0x1000,%rsp
4096 <lrealpath>:  1e50b78:     48 81 ec 00 10 00 00    sub    $0x1000,%rsp

Usual Linux stack is around 8MB, but e.g. on Windows I think just 2MB.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #18 from Sam James <sjames at gcc dot gnu.org> ---
Note that on musl, the default stack size is much smaller:
https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-stack-size.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 4 May 2023, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
> 
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Is there a way to measure peak memory usage in the compiler?

/usr/bin/time will output maxresident, so that's useful for this.

>  I'd like to
> gather some stats.  Also do we have a handful of programs we typically use to
> measure memory usage?  ISTR that Richard (??) had a set of memory hog programs.

I gathered testcases from compile-time-hog/memory-hog bugzillas and run
them on an automated tester, nothing more.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #20 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jakub Jelinek from comment #17)
> Or just try to check for functions with largest stack usages in cc1plus?
> Doing that on the trunk gives:
> objdump -dr cc1plus | grep
> '>:\|sub.*0x.*[0-9a-f][0-9a-f][0-9a-f][0-9a-f],.*rsp' | awk
> '/>:/{I=$2}/sub.*rsp/{J=gensub(/.*(0x[0-9a-f]+),%rsp/,"\\1","1",$0);
> K=strtonum(J);printf "%d %s %s\n", K, I, $0}' | grep -v 0xffffffffffff |
> sort -nr
> 410440 <_ZN19infer_range_manager17register_all_usesEP9tree_node>:  275120d:
> 48 81 ec 48 43 06 00 	sub    $0x64348,%rsp

That's 410K on the stack. Eek !

It looks to me like the data needs to go into the heap. RAII will help
with tidyup.

> Usual Linux stack is around 8MB, but e.g. on Windows I think just 2MB.

Linux kernel has a script checkstack.pl. This might help.

I will try an experimental build of gcc with -Wstack-usage=100000 and report
back.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #21 from David Binderman <dcb314 at hotmail dot com> ---

Two cases, depending on the text of the warning:

$ fgrep warning: mk.out | fgrep Wstack | fgrep -v "might be unbounded" | fgrep
"usage is"  | sort -rnk 6
../../trunk.year/gcc/gimple-range-infer.cc:360:1: warning: stack usage is
410496 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-cache.cc:1682:1: warning: stack usage is
410496 bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:2822:1: warning: stack usage is 204992 bytes
[-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:2556:1: warning: stack usage is 204960 bytes
[-Wstack-usage=]
../../trunk.year/gcc/value-range.cc:2169:1: warning: stack usage is 164688
bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:5085:1: warning: stack usage is 164576 bytes
[-Wstack-usage=]
../../trunk.year/gcc/gimple-range-edge.cc:117:1: warning: stack usage is 163936
bytes [-Wstack-usage=]
../../trunk.year/gcc/tree-ssa-loop-niter.cc:343:1: warning: stack usage is
123808 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-fold.cc:533:1: warning: stack usage is 123424
bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-cache.cc:1293:1: warning: stack usage is
123312 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-fold.cc:734:1: warning: stack usage is 123232
bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-cache.cc:1154:1: warning: stack usage is
123200 bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:4851:1: warning: stack usage is 123056 bytes
[-Wstack-usage=]
$ 

and

$ fgrep warning: mk.out | fgrep Wstack | fgrep -v "might be unbounded" | fgrep
-v "usage is"  | sort -rnk 7
../../trunk.year/gcc/gimple-range-gori.cc:1465:1: warning: stack usage might be
205360 bytes [-Wstack-usage=]
../../trunk.year/gcc/range-op.cc:5135:1: warning: stack usage might be 165008
bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:604:1: warning: stack usage might be
164352 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:743:1: warning: stack usage might be
164144 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:1187:1: warning: stack usage might be
123280 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-gori.cc:1077:1: warning: stack usage might be
123280 bytes [-Wstack-usage=]
../../trunk.year/gcc/gimple-range-fold.cc:897:1: warning: stack usage might be
123216 bytes [-Wstack-usage=]
$ 

It appears that there are some large stack sizes in various parts of gcc.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #22 from Andrew Macleod <amacleod at redhat dot com> ---
OK, I've finished with my analysis.  There are multiple vectors of attack here,
and we should do them all.   Some where already on my radar for this release
anyway, but this gives a nice tidy place to track them all.

First, the increased size of int_range_max needs to be addressed.    Short term
we could resolve this simply by making int_range<25> instead of int_range<255>.
 That of course papers over the real problem, but still needs addressing.  Aldy
and I are discussing.

Next, prefill_stmt_dependencies exists to short-cut long chains of calls to
range_of_stmt by managing it on a stack. It uses a *lot* less stack calls, but
it is still subject to re-evaluating statements whose dependencies are updated.

ssa-names that have not been calculated have no entry in rangers global cache. 
As soon as they get an entry, they are also given a monotonically increasing
timestamp.  This allows us to quickly see if a dependence has been updated
since a value was last calculated. 

prefill_stmt_dependencies pushes un-evaluated names from statements onto a
stack as they are seen, and evaluating those first, then finally evaluating the
stmt. 

_1012 = PHI <_1947(2), _1011(1016)>

we push _1012, then _1947 and _1011 on the stack to evaluate.  _1011 and _1947
will be evaluated before _1012, thus allowing for a decent calculation of
_1012.

We avoid cycles by providing an initial value for a name when it is first
registered. When we provide this initial value, we also set the timestamp to
"always current" so we don't end up with flip flopping dependencies in cycles
causing each other to be recalculated. When we store the newly calculated
value, we set a proper timestamp.

So, on to the issues that need to be addressed.

1) We unconditionally write the new value calculated to the global cache once
the dependencies are resolved.  This gives it a new timestamp, and thus makes
any other values which used it out of date when they really aren't.   This
causes a lot of extra churn.

TODO: This should be changed to only update it when it actually changes. 
Client code shouldn't have to do this, it shoud be handled right int the
cache's set_global_value ().

2) The initial value we choose is simply VARYING. This is why 1) alone won't
solve this problem.  when we push _1947 on the stack, we set it to VARYING.. 
then proceed down along chain of other dependencies Driven by _1011 which are
resolved first.  When we get back to _1947 finally, we see: 
  _1947 = 77;
which evaluated to [77, 77], and is this different than VARYING, and thus would
cause a new timestamp to be created even if (1) were implemented.

TODO: When setting the initial value in the cache, rather than being lazy and
using varying, we should invoke fold_stmt using get_global_range_query ().  
This will fold the stmt and produce a result which resolved any ssa-names just
using known global values. THis should not be expensive, and gives us a
reasonable first approximation.  And for cases like _1947, the final result as
well.

3) When we first set the intial value for _1947 and give it the ALWAYS_CURRENT
timestamp, we lose the context of when the initial value was set.  So even with
1) & 2) implemented, we are *still* need to set a timestamp for it when its
finally calculated, even though it is the same as the original.  This will
cause any names already evaluated using its range to become stale because we
can't leave it as ALWAYS_CURRENT.    (There are other places where we do need
to be able to re-evaluate.. there are 2 testsuite failures caused by this if we
just leave it as always_current)

TODO: Alter the implementation of ALWAYS_CURRENT such that a name is also given
a timestamp at the time of setting the initial value.   Then set_global_range()
will clear the ALWAYS_CURRENT tag unconditionally, but leave the original
timestamp if the value hasn't changed.  This will then provide an accurate
timestamp for the initial_value.

4) Finally, There are multiple ssa-names that are dependent on _1947. Given the
stack oriented mechanism, the first such case will push the value on the stack
to be resolved, and all the other names that depend on it will use the initial
value.  When we finally get back to evaluating it, if it DID come out
different, then all those names would again be stale, and potentially get
recalculated down the road.  

TODO: This impact could be reduced by increasing the priority of its
evaluation. Instead of waiting for evaluation all the way back to the bottom of
the stack for _1947, when a new stmt is dependent on it, we could instead move
it to the top of the stack for consideration.  We'll still be resolving
dependencies, but it will be properly evaluated sooner than later.    Cycles
will have to be avoided by not re prioritizing any dependencies on statement
which have been "bumped" like this.   You have to put a stake in the ground at
some point and use what you have.

Summary:  These 4 changes should fix the algorithmic issues exposed, and
combined with fixing the memory footprint of int_range-max, we should see a big
different in cases like this.  The overhead of doing the extra work is likely
to be offset by saving in not redoing work.  we shall see.

I will get to these when I return from vacation

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #23 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
An update on the int_range_max memory bloat work.

As Andrew mentioned, having int_range<25> solves the problem, but is just
kicking the can down the road.  I ran some stats on what we actually need on a
bootstrap, and 99.7% of ranges fit in a 3 sub-range range, but we need more to
represent switches, etc.

There's no clear winner for choosing <N>, as the distribution for anything past
<3> is rather random.  What I did see was that at no point do we need more than
125 sub-ranges (on a set of .ii files from a boostrap).

I've implemented various alternatives using a dynamic approach similar to what
we do for auto_vec.  I played with allocating 2x as much as needed, and
allocating 10 or 20 more than needed, as well going from N to 255 in one go. 
All of it required some shuffling to make sure the penalty isn't much wrt
virtuals, etc, but I think the dynamic approach is the way to go.

The question is how much of a performance hit are we willing take in order to
reduce the memory footprint.  Memory to speed is a linear relationship here, so
we just have to pick a number we're happy with.

Here are some numbers for various sub-ranges (the sub-ranges grow automatically
in union, intersect, invert, and assignment, which are the methods that grow in
sub-ranges).

trunk (wide_ints <255>) =>  40912 bytes  
GCC 12 (trees <255>)    =>   4112 bytes
auto_int_range<2>       =>    432 bytes  (5.14% penalty for VRP)
auto_int_range<3>       =>    592 bytes  (4.01% penalty)
auto_int_range<8>       =>   1392 bytes  (2.68% penalty)
auto_int_range<10>      =>   1712 bytes  (2.14% penalty)

As you can see, even at N=10, we're still 24X smaller than trunk and 2.4X
smaller than GCC12 for a 2.14% performance drop.

I'm tempted to just pick a number and tweak this later as we have ultimate
flexibility here.  Plus, we can also revert to a very small N, and have passes
that care about switches use their own temporaries (auto_int_range<20> or
such).

Note that we got a 13.22% improvement for the wide_int+legacy work, so even the
absolute worst case of a 5.14% penalty would have us sitting on a net 8.76%
improvement over GCC12.

Bike shedding welcome ;-)

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #24 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
FYI.  I originally tried new/delete for allocation, which was a tad slower than
ggc_alloc / ggc_free.  Not too much, but measurable.

Another idea would be to have a global obstack which auto_int_range<> uses,
which gets freed at the end of every pass.  This saves us various ggc_free()s
throughout, especially at destruction.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #24)
> FYI.  I originally tried new/delete for allocation, which was a tad slower
> than ggc_alloc / ggc_free.  Not too much, but measurable.
> 
> Another idea would be to have a global obstack which auto_int_range<> uses,
> which gets freed at the end of every pass.  This saves us various
> ggc_free()s throughout, especially at destruction.

I think ggc_{alloc,free} is a no-go.  For now I'd go with new/delete, the
choice of N should be so that we do not get allocation in >90% of the
cases anyway.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
new/delete rather than auto_vec member inside of the type using new/delete?

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 9 May 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
> 
> --- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> new/delete rather than auto_vec member inside of the type using new/delete?

new/delete for growing auto_int_range<> from stack to heap storage
(I didn't see/look at any patches)

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #28 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 55031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031&action=edit
WIP patch for a dynamic int_range<>

Here's my WIP.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comment on attachment 55031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031
WIP patch for a dynamic int_range<>

What I meant is that by using a auto_vec could avoid reimplementing larger
chunks of vec.h/vec.cc for this.
Resizing by adding 10 more ranges can have higher compile time cost than what
vec.cc (calculate_allocation_1) does - doubles the size each time for smaller
sizes and and multiplying previous by 3 / 2 for larger ones.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #30 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #29)
> Comment on attachment 55031 [details]
> WIP patch for a dynamic int_range<>
> 
> What I meant is that by using a auto_vec could avoid reimplementing larger
> chunks of vec.h/vec.cc for this.
> Resizing by adding 10 more ranges can have higher compile time cost than
> what vec.cc (calculate_allocation_1) does - doubles the size each time for
> smaller sizes and and multiplying previous by 3 / 2 for larger ones.

Hmmm, that may require a lot more work reshuffling how irange is implemented
internally.  I'll take a peek, but I can't afford to spend another week on this
;-).  Also, adding 10 or multiplying by 2, or even adding 5 IIRC, didn't make
much of a difference in our benchmarks.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, you don't need to use {,vec_}{safe,quick}_push etc. all the time, just
have auto_vec in there and use .address () on it to give you pointer to the
elements and then .length () / .allocated () and .reserve () to ask for more
elements.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #32 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 9 May 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
> 
> --- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Comment on attachment 55031
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031
> WIP patch for a dynamic int_range<>
> 
> What I meant is that by using a auto_vec could avoid reimplementing larger
> chunks of vec.h/vec.cc for this.
> Resizing by adding 10 more ranges can have higher compile time cost than what
> vec.cc (calculate_allocation_1) does - doubles the size each time for smaller
> sizes and and multiplying previous by 3 / 2 for larger ones.

If we still have a hard limit on the MAX number of ranges (previosly 255)
then I'd probably go straight from stack -> that MAX and never re-allocate
further?

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That would indeed simplify things and auto_vec member would be unnecessary, nor
any of the length/allocated members etc.  All we'd need is just a pointer and
small size buffer (and is_small check would be pointer == &small_size_buffer).

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #34 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Excellent ideas!

For that matter, we may get away with defaulting to 3 sub-ranges and always
resizing as needed (up to MAX).  Needing more than 3 sub-ranges is so rare
(less than 0.5% of the time), that the penalty will be small.

Furthermore, these defaults are sensible enough that we could nuke int_range<N>
altogether and have irange have this small [3*2] array.  After all, most uses
of int_range<N> now are int_range_max, since we never know the size of the
range (except in rare cases such as boolean_type_node, etc).  This would
simplify the code and get rid of the annoying templates which I hate.  No need
for int_range_max, or int_range<N>, etc.  Just plain irange.

This would give us an irange of 592 bytes compared to 40912 for int_range_max
currently.  Plus, it's not that far away from int_range<2> which currently is
432 bytes, and as I mentioned, barely happens as we mostly use int_range_max.

I think this is a nice trade off.  Cleaner more flexible code, without
templates.

Oh... preliminary tests show it's a 5% penalty for VRP, which is more than
covered by our 13.22% improvement (plus Andrew's cache improvements) to VRP.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #35 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
We could also tweak the number of sub-ranges.  8 (??) also sounds good for a
few percent less in performance drop, if we care.

p.s. I did try the auto_vec thing for a 25% loss in VRP performance, even when
using address(), reserve(), etc.  I may have gotten something wrong, but it
didn't look promising.  I could post my attempt and someone could take it from
there, but I think the one irange approach with sensible defaults that
automatically grow to MAX, better.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:76e11280e79c5dd5089c17d5726cae9a5a21bc2e

commit r14-862-g76e11280e79c5dd5089c17d5726cae9a5a21bc2e
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Mon May 15 12:25:58 2023 +0200

    Add auto-resizing capability to irange's [PR109695]

    <tldr>
    We can now have int_range<N, RESIZABLE=false> for automatically
    resizable ranges.  int_range_max is now int_range<3, true>
    for a 69X reduction in size from current trunk, and 6.9X reduction from
    GCC12.  This incurs a 5% performance penalty for VRP that is more than
    covered by our > 13% improvements recently.
    </tldr>

    int_range_max is the temporary range object we use in the ranger for
    integers.  With the conversion to wide_int, this structure bloated up
    significantly because wide_ints are huge (80 bytes a piece) and are
    about 10 times as big as a plain tree.  Since the temporary object
    requires 255 sub-ranges, that's 255 * 80 * 2, plus the control word.
    This means the structure grew from 4112 bytes to 40912 bytes.

    This patch adds the ability to resize ranges as needed, defaulting to
    no resizing, while int_range_max now defaults to 3 sub-ranges (instead
    of 255) and grows to 255 when the range being calculated does not fit.

    For example:

    int_range<1> foo;       // 1 sub-range with no resizing.
    int_range<5> foo;       // 5 sub-ranges with no resizing.
    int_range<5, true> foo; // 5 sub-ranges with resizing.

    I ran some tests and found that 3 sub-ranges cover 99% of cases, so
    I've set the int_range_max default to that:

            typedef int_range<3, /*RESIZABLE=*/true> int_range_max;

    We don't bother growing incrementally, since the default covers most
    cases and we have a 255 hard-limit.  This hard limit could be reduced
    to 128, since my tests never saw a range needing more than 124, but we
    could do that as a follow-up if needed.

    With 3-subranges, int_range_max is now 592 bytes versus 40912 for
    trunk, and versus 4112 bytes for GCC12!  The penalty is 5.04% for VRP
    and 3.02% for threading, with no noticeable change in overall
    compilation (0.27%).  This is more than covered by our 13.26%
    improvements for the legacy removal + wide_int conversion.

    I think this approach is a good alternative, while providing us with
    flexibility going forward.  For example, we could try defaulting to a
    8 sub-ranges for a noticeable improvement in VRP.  We could also use
    large sub-ranges for switch analysis to avoid resizing.

    Another approach I tried was always resizing.  With this, we could
    drop the whole int_range<N> nonsense, and have irange just hold a
    resizable range.  This simplified things, but incurred a 7% penalty on
    ipa_cp.  This was hard to pinpoint, and I'm not entirely convinced
    this wasn't some artifact of valgrind.  However, until we're sure,
    let's avoid massive changes, especially since IPA changes are coming
    up.

    For the curious, a particular hot spot for IPA in this area was:

    ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
    {
    ...
    ...
      value_range save (m_vr);
      m_vr.union_ (*other_vr);
      return m_vr != save;
    }

    The problem isn't the resizing (since we do that at most once) but the
    fact that for some functions with lots of callers we end up a huge
    range that gets copied and compared for every meet operation.  Maybe
    the IPA algorithm could be adjusted somehow??.

    Anywhooo... for now there is nothing to worry about, since value_range
    still has 2 subranges and is not resizable.  But we should probably
    think what if anything we want to do here, as I envision IPA using
    infinite ranges here (well, int_range_max) and handling frange's, etc.

    gcc/ChangeLog:

            PR tree-optimization/109695
            * value-range.cc (irange::operator=): Resize range.
            (irange::union_): Same.
            (irange::intersect): Same.
            (irange::invert): Same.
            (int_range_max): Default to 3 sub-ranges and resize as needed.
            * value-range.h (irange::maybe_resize): New.
            (~int_range): New.
            (int_range::int_range): Adjust for resizing.
            (int_range::operator=): Same.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #37 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to CVS Commits from comment #36)

>     For the curious, a particular hot spot for IPA in this area was:
>     
>     ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
>     {
>     ...
>     ...
>       value_range save (m_vr);
>       m_vr.union_ (*other_vr);
>       return m_vr != save;
>     }
>     
>     The problem isn't the resizing (since we do that at most once) but the
>     fact that for some functions with lots of callers we end up a huge
>     range that gets copied and compared for every meet operation.  Maybe
>     the IPA algorithm could be adjusted somehow??.

isn't the the same thing as 

  return m_vr.union_ (*other_vr);

which should be much faster without all the copying... ?

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #38 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #37)
> (In reply to CVS Commits from comment #36)
> 
> >     For the curious, a particular hot spot for IPA in this area was:
> >     
> >     ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
> >     {
> >     ...
> >     ...
> >       value_range save (m_vr);
> >       m_vr.union_ (*other_vr);
> >       return m_vr != save;
> >     }
> >     
> >     The problem isn't the resizing (since we do that at most once) but the
> >     fact that for some functions with lots of callers we end up a huge
> >     range that gets copied and compared for every meet operation.  Maybe
> >     the IPA algorithm could be adjusted somehow??.
> 
> isn't the the same thing as 
> 
>   return m_vr.union_ (*other_vr);
> 
> which should be much faster without all the copying... ?

Indeed.  That is in the committed version of the patch.  I just forgot to
update the message.

The reason I didn't originally do as you suggested was that there was a bug in
the union code that returned TRUE for a union that hadn't changed anything. 
That has also been fixed in trunk.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #39 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:d8b058d3ca4ebbef5575105164417f125696f5ce

commit r14-1163-gd8b058d3ca4ebbef5575105164417f125696f5ce
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue May 23 15:11:44 2023 -0400

    Choose better initial values for ranger.

    Instead of defaulting to VARYING, fold the stmt using just global ranges.

            PR tree-optimization/109695
            * gimple-range-cache.cc (ranger_cache::get_global_range): Call
            fold_range with global query to choose an initial value.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #40 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:cfd6569e9c41181231a8427235d0c0a7ad9262e4

commit r14-1164-gcfd6569e9c41181231a8427235d0c0a7ad9262e4
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue May 23 15:20:56 2023 -0400

    Use negative values to reflect always_current in the temporal cache.

    Instead of using 0, use negative timestamps to reflect always_current
state.
    If the value doesn't change, keep the timestamp rather than creating a new
    one and invalidating any dependencies.

            PR tree-optimization/109695
            * gimple-range-cache.cc (temporal_cache::temporal_value): Return
            a positive int.
            (temporal_cache::current_p): Check always_current method.
            (temporal_cache::set_always_current): Add param and set value
            appropriately.
            (temporal_cache::always_current_p): New.
            (ranger_cache::get_global_range): Adjust.
            (ranger_cache::set_global_range): set always current first.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

--- Comment #41 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:257c2be7ff8dfdc610202a1e1f5a8a668b939bdb

commit r14-1165-g257c2be7ff8dfdc610202a1e1f5a8a668b939bdb
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue May 23 15:41:03 2023 -0400

    Only update global value if it changes.

    Do not update and propagate a global value if it hasn't changed.

            PR tree-optimization/109695
            * gimple-range-cache.cc (ranger_cache::get_global_range): Add
            changed param.
            * gimple-range-cache.h (ranger_cache::get_global_range): Ditto.
            * gimple-range.cc (gimple_ranger::range_of_stmt): Pass changed
            flag to set_global_range.
            (gimple_ranger::prefill_stmt_dependencies): Ditto.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #42 from Andrew Macleod <amacleod at redhat dot com> ---
I think we can close this now, I think everything we plan to do has been done.