https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> --- hmm. yeah. its triggering some kind of pathological edge evaluation between GORI and cache updating. There is a long sequence of dependent stmts, presumably the unrolled loop, and a sequential series of conditions.. ie: _4 = (short unsigned int) c.2_1; _5 = _4 + 65535; a_lsm.19_30 = a; _49 = _4 + 65534; _12 = _5 & _49; _46 = _12 + 65535; _48 = _12 & _46; _59 = _48 + 65535; _60 = _48 & _59; <...> if (_12 != 0) if (_48 != 0) if (_60 != 0) <...> note the interdependence of say _48 and _12. Evaluating _48 evaluates _12 and _46. _46 evaluates _12 as well, and then it continues.. Edge evaluation still has no caching, so its calculated as required. This is causing a cascading exponential growth of edge evaluations the further we go. Caching outgoing edge evaluations should resolve this, as would identifying the situation with 2 operands that have an interdependence and evaluating them together rather than independently, thus removing the exponential explosion. still considering... .
