https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100081
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
OMG. Don't bother reducing. I can see the problem.
EVRP is fine, but when wrestrict runs, its quite late, and the CFG has
<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%]
Its a 7200 stmt basic block, made up of calculations and 2614 ORs and 1480
ANDs.
A request is made for a range which can be exported from this block, and ranger
is dutifully trying everything it can to process those blocks.
Each AND/OR is a logical expression which evaluates a TRUE and FALSE range for
each operands, so it calculates up to 4 ranges for each pair of operands. I
knew this could get out of hand in pathological cases, so we introduced a
logical cache to help resolve this and avoid extra work. Its actually making
this one worse I think.
Regardless, I know what the issue is. I have 2 things to try.
1) We have a patch in our branch that gives up early.. once it finds the result
is going to be varying... I'll give that a shot first, it may stop this
lookup quickly. Its possible it won't.
if not, then
2) we've also discussed that in ridiculously large combinations of &&/|| we are
unlikely to be able to haul a useful range out of it, so limit the depth of
logical processing to something in a reasonable range. 4000 logicals operations
is not reasonable to look thru. something more akin to 10 maybe at most..
Anyway, I know what the issue is and will have it resolved early next week at
the latest.
