https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #11) > (In reply to Richard Biener from comment #10) > > (In reply to Andrew Macleod from comment #9) > > > Created attachment 57620 [details] > > > proposed patch > > > > > > Does this solve your problem if there is an active ranger? it bootstraps > > > with no regressions > > > > I'll check what it does. > > > So the important part is that it got the fact that _12 is positive. As > analyzed in earlier comments I think that's all we can do, we don't know > anything about the other variable involved and thus can't avoid the > unsigned punning during SCEV analysis. Yeah, I wouldn't want to invoke any dynamic lookup changes at this point. that would be too hard to predict or contain. I will continue poking at what is triggering the loop issues because I think its a good longer term solution to have range_of_expr with no context to invoke range_of_stmt if the DEF is in the IL and has not been processed. > > I think it's a good change, let's keep it queued for stage1 at this point > unless we really know a case it helps to avoid a regression with > r14-9193-ga0b1798042d033 > > For testing, what's the "easiest" pass/thing to do to recompute global > ranges now? In the past I'd schedule EVRP but is there now a ranger > API to do this? Just to see if full global range compute before IVOPTs > would help. all VRP passes are the same now. so just schedule EVRP. in theory, you could schedule the fast vrp pass I added, but its not heavily tested... but you could try it. It doesnt do any back edges or switches (iirc), but does basic calculations in DOM order and exports/updates globals. NEXT_PASS (pass_fast_vrp)
