https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 22 Nov 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598 > > --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > While it might look too specialized, it actually triggered (i.e. narrowed the > range info) in 105473 cases during x86_64-linux bootstrap + regtest. > --- gcc/tree-ssa-phiopt.c.jj 2018-11-22 18:45:54.670669434 +0100 > +++ gcc/tree-ssa-phiopt.c 2018-11-22 18:49:01.225590302 +0100 > @@ -266,7 +266,14 @@ tree_ssa_phiopt_worker (bool do_store_el > min2 = wi::add (min2, 1); > else > max2 = wi::sub (max2, 1); > +{ > +FILE *f = fopen ("/tmp/phiopt", "a"); > +fprintf (f, "@ %d %s %s\n", (int) BITS_PER_WORD, main_input_filename ? > main_input_filename : "-", current_function_name ()); > +dump_ssaname_info_to_file (f, phi_lhs, 0); > set_range_info (phi_lhs, VR_RANGE, min2, max2); > +dump_ssaname_info_to_file (f, phi_lhs, 0); > +fclose (f); > +} > } > } > } > hack is what I've used to gather this info. > Thinking about it, it might be better to stick it somewhere else, where we > walk > PHI arguments (it would be cheaper to look for all phi arguments constants > except one SSA_NAME from edge that ends in GIMPLE_COND comparison of that > against constant). > That said, I'm not really familiar with the evrp analyzers and how expensive > they are, ideally this should be kept as something super cheap. And don't > really understand how union_ would be helpful, what we want here is not union, > but narrowing the range. Recomputing the range from scratch is possible but > it > would be still better to compare it against the already recorded range and > only > narrow it, never extend. You need to union the PHI argument ranges. The result you can intersect with the existing range info of the PHI result of course. You basically want to do to the PHI what [E]VRP does ... It's phiopt2 where this is important for the testcase? Or phiopt3 after loop? Because after loop there's forwprop before and ccp after phiopt both of which would be a better fit. Late CCP probably doesn't need to be the SSA-propagator-iterating variant but could do with a simpler DOM-style approach and thus could be replaced by EVRP if it weren't for that lacking the alignment/nonzero bits computation... So I fear any "proper" solution isn't for stage3 but still I'd go with factoring (enough of) vr_values::extract_range_from_phi_node plus the register_edge_asserts thing if we need to look at dominating conditions. I also wouldn't restrict it to the case of all-constant PHI args but one that gets range info from a dominating condition but simply re-process ranges for all PHIs. That said, forwprop already tracks copies and constants and walks PHI args so maybe you can fit the logic there?
