https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #40 from Andrew Macleod <amacleod at redhat dot com> --- > There is no problem with adding --params, and those are always better than > magic numbers. > > Btw, I originally wondered why we don't re-compute zone1_12 because it's > in the imports of the successor (OK, the empty successors single successor > block) and expected those to trigger re-computes. Yeah, I don't like magic number either. I vaguely recall that it changed the footprint of something and caused linking issues with something else requiring complete rebuilds which annoyed some people.. but I have lost the context. Recomputes have nothing to do with imports, its all about exports. Exports drive the range engine... they are the things that change on exit to block based on the edge taken. Imports are things which can affect an export. So in some iterative/analytical world, if the imports to a block do not change, the exports will not change either. Recomputes are about having an export from a block in your definition chain. This means you are only indirectly related to the export. If the export changes, then your value may also change if you can be recalculated using the export. This issue is fundamentally about how much effort we make into looking if you can be recomputed. Its turns out the underlying engine is more efficient than I realized, and once we indicate it can be calculated, the calculation itself is actually linear. If we stick to single ssa-names dependencies, then even though the lookup is currently quadratic, for smallish numbers, its pretty minimal impact. Most cases I've seen that are of impact seem to be a sequence involving a few casts. The current patchset with a depth of 5 catches the vast majority of things, and is not that expensive.
