https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100844
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2021-06-01
Keywords| |compile-time-hog
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, repetitive lines can be abbreviated using macros like
#define WONE while (n--)
#define WTEN WONE WONE WONE WONE WONE WONE WONE WONE WONE WONE
#define WHUNDRED WTEN WTEN WTEN WTEN WTEN WTEN WTEN WTEN WTEN WTEN
WHUNDRED WHUNDRED WTEN WTEN
for two hundred twenty repetitions of while (n--). Your testcase doesn't
reproduce the ICE for me. I'm quite sure you're running into a stack
overflow due to some recursive (in loop depth) algorithm in GCC. Lowering
the stack ulimit from 8MB to 2MB makes it run into
#0 0x00000000012005f9 in expr_expected_value_1 (
type=<error reading variable: Cannot access memory at address
0x7fffffdfefb8>,
op0=<error reading variable: Cannot access memory at address
0x7fffffdfefb0>, code=<error reading variable: Cannot access memory at address
0x7fffffdfefac>,
op1=<error reading variable: Cannot access memory at address
0x7fffffdfefa0>,
visited=<error reading variable: Cannot access memory at address
0x7fffffdfef98>,
predictor=<error reading variable: Cannot access memory at address
0x7fffffdfef90>, probability=0x7fffffdff310)
at /home/rguenther/src/gcc4/gcc/predict.c:2362
#1 0x0000000001200a40 in expr_expected_value_1 (
type=<integer_type 0x7ffff6583690 unsigned int>,
op0=<ssa_name 0x7ffff61cf798 6222>, code=SSA_NAME, op1=<tree 0x0>,
visited=0x7fffffffd910, predictor=0x7fffffdff318,
probability=0x7fffffdff310) at /home/rguenther/src/gcc4/gcc/predict.c:2451
...
#8828 0x00000000012008dd in expr_expected_value_1 (type=<integer_type
0x7ffff6583690 unsigned int>, op0=<ssa_name 0x7ffff65755e8 1973>,
code=SSA_NAME, op1=<tree 0x0>, visited=0x7fffffffd910,
predictor=0x7fffffffd8bc, probability=0x7fffffffd8b0) at
/home/rguenther/src/gcc4/gcc/predict.c:2423
#8829 0x00000000012013af in expr_expected_value (expr=<ssa_name 0x7ffff65755e8
1973>, visited=0x7fffffffd910, predictor=0x7fffffffd8bc,
probability=0x7fffffffd8b0) at /home/rguenther/src/gcc4/gcc/predict.c:2641
#8830 0x0000000001201085 in expr_expected_value_1 (type=<boolean_type
0x7ffff6583b28 _Bool>, op0=<ssa_name 0x7ffff65755e8 1973>, code=NE_EXPR,
op1=<integer_cst 0x7ffff656af60>, visited=0x7fffffffd910,
predictor=0x7fffffffd8bc, probability=0x7fffffffd8b0) at
/home/rguenther/src/gcc4/gcc/predict.c:2575
#8831 0x00000000012016d0 in tree_predict_by_opcode (bb=<basic_block
0x7ffff627f068 (4)>) at /home/rguenther/src/gcc4/gcc/predict.c:2709
#8832 0x0000000001202aa1 in tree_estimate_probability_bb (bb=<basic_block
0x7ffff627f068 (4)>, local_only=false) at
/home/rguenther/src/gcc4/gcc/predict.c:3096
#8833 0x0000000001202b65 in tree_estimate_probability (dry_run=false) at
/home/rguenther/src/gcc4/gcc/predict.c:3126
#8834 0x0000000001206094 in (anonymous namespace)::pass_profile::execute
(this=0x3793f30, fun=0x7ffff66c6000) at
/home/rguenther/src/gcc4/gcc/predict.c:4102
#8835 0x00000000011e8147 in execute_one_pass (pass=<opt_pass* 0x3793f30
"profile_estimate"(53)>) at /home/rguenther/src/gcc4/gcc/passes.c:2567
so it's not really loop depth but a large dependent expression. The
unlimited expr walk is also a possible compile-time issue - for binary
ops it brances off to both arms even. The whole thing is a bit odd,
probably wanting to only sparsely evaluate "expected values" but ending
of evaluating things more than once if exprs are reached by multiple
"last stmts". A forward sweep over the IL would lose sparseness but
would remove the recursion and make the whole thing predictiable.
Alternatively using a worklist and a SSA def "likely value" cache for
all expr evaluations might preserve the sparseness but at bigger
constant cost.
Btw, I've never seen this function on the radar for "real" code.
