https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 23 Nov 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598 > > --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > So, evrp_range_analyzer.enter (bb); even calls record_ranges_from_phis, but > that does nothing here, as only one of the preds is BB_VISITED and the other > is > not when this is called, so we end up with has_unvisited_preds and so > extract_range_from_phi_node isn't called. Could we just drop the > has_unvisited_preds stuff and instead in extract_range_from_phi_node for the > edges from non-visited bbs solely use get_range_info? We could do that, yes. > Plus, we'd need for both the visited and unvisited add the range intersection > with the guarding condition of the edge if it uses the same SSA_NAME (or > perhaps later extend it to be as smart as tree-vrp.c assertion handling is, it > handles even some more complex cases). Or is it that in evrp code we never > want to look at recorded SSA_NAME_RANGE_INFO? EVRP already factors this in. Thus record_ranges_from_incoming_edge is assumed to adjust the range info in the (temporary) lattice. > And lastly, even if all this is done, I believe dom just computes ranges, but > doesn't every adjust (narrow) recorded SSA_NAME_RANGE_INFO if it computes > something more precise for some SSA_NAME. Can it do that? The EVRP analysis code does so. But yes, if DOM simplifies sth the range code isn't re-done. IIRC I once tried switching the two calls in edge taken_edge = NULL; for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi)) { evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (gsi), false); taken_edge = this->optimize_stmt (bb, gsi); } or I even did?
