https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #6 from bin cheng <amker at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #5)
> (In reply to bin cheng from comment #4)
> > In get_scaled_computation_cost_at, we have very big ratio between
> > bb_count/loop_count:
> >
> > (gdb) p data->current_loop->latch->count
> > $50 = {static n_bits = 61, static max_count = 2305843009213693950, static
> > uninitialized_count = 2305843009213693951, m_val = 158483, m_quality =
> > profile_guessed_local}
> > (gdb) p gimple_bb(at)->count
> > $51 = {static n_bits = 61, static max_count = 2305843009213693950, static
> > uninitialized_count = 2305843009213693951, m_val = 1569139790, m_quality =
> > profile_guessed_local}
> > (gdb) p 1569139790 / 158483
> > $52 = 9900
> > (gdb) p cost
> > $53 = {cost = 20, complexity = 2, scratch = 1}
> > (gdb) p 19 * 9900
> > $54 = 188100
> >
> > as a result, sum_cost soon reaches to overflow of infinite_cost. Shall we
> > cap the ratio so that it doesn't grow too quick? Of course, some benchmark
> > data is needed for this heuristic tuning.
>
> I would implement the capping in comp_cost struct where each individual
> operator
> can cap to infinite. What do you think Bin?
Implementing the capping in comp_cost::operators to infinite_cost is less
invasive. OTOH, capping bb_freq/loop_freq has its own advantages, because:
Once cost reaches to infinite, it becomes meaningless in comparison as well as
candidate choosing; capping bb_freq/loop_freq can still express hotness of
code to some extend.
Let's fix the issue by capping comp_cost::operators first for this stage 4 and
revisit the idea capping bb_freq/loop_freq with more benchmark data in next
Stage 1. How about that?
Thanks.
>
> >
> >
> > Another problem is the generated binary has segment fault issue even
> > compiled O0:
> >
> > $ ./g++ -O0 pr90078.cc -o a.out -ftemplate-depth=1000000 -ftime-report -g
> > -std=c++14
> > $ gdb --args ./a.out
> >
> > Dump of assembler code for function main():
> > 0x0000000000400572 <+0>: push %rbp
> > 0x0000000000400573 <+1>: mov %rsp,%rbp
> > 0x0000000000400576 <+4>: sub $0x2625a020,%rsp
> > 0x000000000040057d <+11>: lea -0x2625a020(%rbp),%rax
> > 0x0000000000400584 <+18>: mov %rax,%rdi
> > => 0x0000000000400587 <+21>: callq 0x4006c0 <Tensor4<float, 100, 100,
> > 100, 100>::Tensor4()>
> > 0x000000000040058c <+26>: lea -0x4c4b410(%rbp),%rax
> > 0x0000000000400593 <+33>: lea -0xe4e1c10(%rbp),%rdx
> >
> > The segment fault happens at the callq instruction.
>
> Yes, same happens also for clang. It's a stack overflow:
>
> $ g++ pr90078.cpp -ftemplate-depth=1111111 -fsanitize=address && ./a.out
> AddressSanitizer:DEADLYSIGNAL
> =================================================================
> ==5750==ERROR: AddressSanitizer: stack-overflow on address 0x7fffd9da3af0
> (pc 0x0000004011cb bp 0x7fffffffdc60 sp 0x7fffd9da3af0 T0)
> #0 0x4011ca in main (/home/marxin/Programming/testcases/a.out+0x4011ca)
> #1 0x7ffff6d32b7a in __libc_start_main ../csu/libc-start.c:308
> #2 0x401109 in _start (/home/marxin/Programming/testcases/a.out+0x401109)
>
> SUMMARY: AddressSanitizer: stack-overflow
> (/home/marxin/Programming/testcases/a.out+0x4011ca) in main
> ==5750==ABORTING
