https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Andrew Macleod from comment #5) > (In reply to Jakub Jelinek from comment #4) > > Even then, I wonder why ranger doesn't figure this out. > > (x+1u) <= 2 ? x : 0 > > must have a range [-1, 1] and [-1, 1] / [2, 2] range should be [0, 0], no? > > its because there is no branch which is what drives ranger. At this point, > we aren't quite smart enough to completely evaluate the 2 operands of a > conditional as if they were actual branches. > ie > _1 = x_4(D) + 1; > _10 = (unsigned int) x_4(D); > _6 = _10 + 2; > _7 = _6 <= 2; > _2 = _7 ? _1 : 0; > > if that were: > if (_6 <= 2) > _2 = _1 > we'd recalculate _1 with the condition being (_6 <= 2) and we come upwith > [-1, 1] for _1 instead of varying. > > I'll have to look at whats involved in enhancing the fold code to invoke > GORI to reevaluate _1 if _7 is [1,1]. in theory is not too difficult... :-) ah, its more complicated than that. we normally do this evaluation, but the cond_expr is using _1.. if you trace back from _6 in the condition, _1 is not in the dependency chain anywhere, so GORi cannot compute anything for it. it can compute that x_4 is [-2, 0] but it doesnt see any connection between _6 in the condition and _1. the remaining question is whether this can be cheaply identified as a recomputation.. in which case we could recompute _1 usin the [-2, 0] for x_4 and come up with [-1, 1] I'll have a look if we can easily invoke hte recompuation code the edges evaluations use or nor
