https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 54445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54445&action=edit proposed patch I finally reproduced it, the following patch is in testing. In the referenced commit, I changed it so cache propagation would use better values from the DOM tree if there was nothing in the current block. I changed the external cache API to do this rather than reverting to using the internal API. The result was when GORI is calculating outgoing ranges, if it finds a recomputation candidate, it invokes the caches range_on_edge API to resolve the operands of the recompution. With my earlier change, this could do a search of the DOM tree for a better value. With the proer set of cascading expressions feeding each other this could be a quadratic cost, approaching exponential. Doh. The correct fix is to revert the range_on_edge external API to return to its original approach of just using whats handy, and instead change range_from_dom to use the internal API since it knows what its doing, and check the dom tree for a better value. This could in theory be the cause of other time hogs recently, especially in DOM.
