https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #30 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Richard Biener from comment #15) > We're also doing a lot of redundant stmt simplifications by likely > quadratically > exploring jump threading paths. And each hybrid_jt_simplifier::simplify > call resets the path query path which we know is a very expensive operation, > it also shares the issues the backwards threader originally had, starting > with too big imports. Doing that up to 2^four times for each block is > wasteful - simplify_control_stmt_condition_1 ends up calling > hybrid_jt_simplifier::simplify through dom_jt_simplifier::simplify and > while simplify_control_stmt_condition_1 has a recursion limit while > processing & and | it recurses to both arms, something ranger can do > itself(?). The recursion over & and | is indeed suspect, as ranger can handle all of this itself. I suspect most of simplify_control_stmt_condition_1() can go away. I'll look into this. > > The threader JT simplifier is over-abstracted - only DOM seems to use > hybrid_jt_simplifier. The following should cut compile-time down > significantly (I'm not sure if the "old" DOM equiv lookup done by > dom-simplify is even necessary). IMO "gimping" the old forward threader > with ranger was misguided as it was supposed to vanish anyway. You are correct, the use of ranger in the forward threader was a bit of a hack, but a necessary one nevertheless, as otherwise we'd need to keep the old VRP code around just for this pass. Keeping old VRP was a maintenance burden. The old DOM equiv lookup is still needed as it handles pointer equivalences which prange does not (yet). It also simplifies some floating point operations that we need to audit and make sure frange handles (it probably does, I just haven't checked yet). So yes, the old forward threader is slated for removal, but we need to address the above two items.
