https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 57638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57638&action=edit patch Ok, there were 2 issues with simply invoking range_of_stmt, which this new patch resolves. IF we aren't looking to fix this in GCC 14 right now anyway, this is the way to go. 1) The cache has always tried to provide a global range by pre-folding a stmt for an estimate using global values. This is a bad idea for PHIs when SCEV is invoked AND SCEV is calling ranger. This changes it to not pre-evaluate PHIs, which also saves time when functions have a lot of edges. Its mostly pointless for PHIs anyway since we're about to do a real evaluation. 2) The cache's entry range propagator was not re-entrant. We didn't previously need this, but with SCEV (and possible other place) invoking range_of_expr without context and having range_of_stmt being called, we can occasionally get layered calls for cache filling (of different ssa-names) With those 2 changes, we can now safely invoke range_of_stmt from a contextless range_of_expr call. We would have tripped over this earlier if SCEV or one of those other places using range_of_expr without context had instead invoked range_of_stmt. That would have been perfectly reasonable, and would have resulting in these same issues. We never tripped over it because range_of_stmt is not used much outside of ranger. That is the primary reason I wanted to track this down. There were alternative paths to the same end result that would have triggered these issues. Give this patch a try. it also bootstraps with no regressions. I will queue it up for stage 1 instead assuming all is good.
