https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- In theory the jump-threading code could go down and make the evrp_range_analyzer process the new blocks but I'm not sure how well this works out given the actual code transform is done after all analysis and thus we'd have to re-run the analyzer and the code transform likely ends up with not updated SSA form before it calls update_ssa. The jump threading code might want to run CSE on the duplicated paths and I have thought about adding a value-range lattice to RPO VN (it's probably moderately easy to retro-fit it into the non-iterating variant). But I think this all is nothing for stage3... Remains (given jump-threading creates paths with just falltru-edges?) to call the range analyzing routines on each stmt, maintaining our own lattice. Like if we'd be folding each stmt. The simplest interface for this is using vr_values::extract_range_from_stmt / set_vr_value and push the result to the SSA def. It might not deal with unvisited DEFs properly though (they'll be UNDEFINED I guess), so you'd have to maintain a visited bitmap and seed unvisited ops with a VARYING range if you run into them. Or you need to teach vr_values to not do that.
