[Bug tree-optimization/93084] Infinite loop in ipa-cp when building clang with LTO+PGO

2019-12-27 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-28
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
OK, I tested that the following hack
Index: ipa-cp.c
===
--- ipa-cp.c(revision 279724)
+++ ipa-cp.c(working copy)
@@ -2019,7 +2019,7 @@ propagate_vals_across_arith_jfunc (cgrap
   /* Recursively generate lattice values with a limited count.  */
   FOR_EACH_VEC_ELT (val_seeds, i, src_val)
{
- for (int j = 1; j < param_ipa_cp_max_recursive_depth; j++)
+ for (int j = 1; j < param_ipa_cp_max_recursive_depth && 0; j++)
{
  tree cstval = get_val_across_arith_op (opcode, opnd1_type, opnd2,
 src_val, res_type);

lets compilation to finish. So I guess we need to figure out why number of
values is getting out of hand.

[Bug tree-optimization/93084] Infinite loop in ipa-cp when building clang with LTO+PGO

2019-12-27 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084

Jan Hubicka  changed:

   What|Removed |Added

 CC||fxue at os dot 
amperecomputing.com

--- Comment #2 from Jan Hubicka  ---
Also adding Feng since this seems to be caused by the new recursive cloning
code. As far as i can tell, the code is just propagating the loop around the
SCC component.

[Bug tree-optimization/93084] Infinite loop in ipa-cp when building clang with LTO+PGO

2019-12-27 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #1 from Jan Hubicka  ---
OK, I looked into this bit more.  propagate_constants_topo never ends
and most of time is spent by comparing values in add_value so each invocation
of propagate_vals_across_arith_jfunc takes about a second or two.

Problem is that dest_lat is very large
(gdb) p *dest_lat
$46 = {values = 0xd2f9f58, values_count = 1114, contains_variable = true,
bottom = false}

there is parameter UNLIMITED to add_value which is responsible for letting the
list to become so long. Printing the lattice gets me results like:
   18446744073709550540 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550539 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550538 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550537 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550536 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550535 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550534 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550533 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550532 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550531 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550530 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550529 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550528 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550527 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550526 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550525 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550524 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550523 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550522 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550521 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550520 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550519 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550518 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550517 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550516 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550515 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550514 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550513 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550512 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550511 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550510 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550509 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550508 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550507 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550506 [from: 1977266(0.500222)] [loc_time: 0,
loc_size: 0, prop_time: 0, prop_size: 0]
   18446744073709550505 [from: 1977266(0.500222)] [loc_time: 0,
lo