https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 54973 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54973&action=edit Patch to fix the issue The problem was exposed by the newly increased size of int_range_max. (We may want to address that elsewhere) It has grown an order of magnitude in size with wide-int To avoid massive stack growth, range_of_stmt uses prefill_stmt_dependencies() to do the same thing as a set of nested recursive calls to range_of_stmt, just managing it via a stack of ssa-names instead of actual calls. Once all the dependencies have been resolved, then we invoke fold_stmt and evaluate the stmt, and set the result. The problem is that while processing a series of PHIs, some ssa-names occur multiple times, and setting the result was unconditionally done. In this case, it was really simple: _1947 = 77; _1947 was used in multiple phi arguments, as well as other stmts which then fed long series of PHIs. it always came up as [77, 77], but when the global value was set again, it changes the temporal timestamp. The next time it was seen, it was "newer" than the previously calculated value, and we therefore thought we had to go and prefetch things again. It effectively un-did much of the pre-fetching, and we'd end up with very long call chains again. With the increased size of int_range_max, it blew up the stack in this testcase. The fix is to simply check if the new value is different than the previous value, and not set it if so. This would be appropriate to put into gcc13 as well. Patch is currently undergoing testing
