https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #16 from Andrew Macleod <amacleod at redhat dot com> --- Looking back at this, I explained why its pathological, but I realize I wasn't clear about a couple of things. So for the record :-) > > <bb 560> [local count: 28382607]: > > <...> > > _571 = _61 >= _593; > > _3583 = &arr_724 + _3992; > > _2220 = _831 <= _3583; > > _47 = _571 | _2220; > > _2935 = _376 * 2; > > _3966 = &arr_725 + _2935; > > _3024 = _61 >= _3966; > > _4219 = _3992 * 2; > > _4218 = &arr_725 + _4219; > > _1836 = _831 <= _4218; > > _3080 = _1836 | _3024; > > <...> > > _5348 = _5347 & _32080; > > _5349 = _5348 & _32151; > > _5350 = _5349 & _32176; > > _5351 = _5350 & _32488; > > _5352 = _5351 & _33691; > > _5353 = _5352 & _33762; > > _5354 = _5353 & _34753; > > _35662 = _5354 & _34824; > > if (_35662 != 0) > > goto <bb 561>; [90.00%] > > else > > goto <bb 1510>; [10.00%] We do create ranges for everything as we go thru this block. the forward walk which calculates ranges is linear, and everything does get calculated. _61 will have a range, and when we get to _3024 = _61 >= _3966; it will either evaluate to [0,0], [1,1], or [0,1] depending on its value. Assume that it evaluates to [0,1] AKA varying. What will not happen now is we do not try to figure out if its [0,0] or [1,1] on either of the outgoing edges. To answer that question, we have to know whether _3024 is [0,0] or [1,1] on the outgoing edge. Trying to determine that through too many combinations of || and && is expensive/exponential, and I detailed in my description why that is. As long as there are not too many logical combining operations, we will make an attempt to determine its range by checking the possible paths thru those logical expressions. If it too complicated, you are stuck with whatever range we could figure out via the linear walk.
