On Tue, Dec 2, 2025 at 1:37 PM Andrew MacLeod <[email protected]> wrote: > > The record() and register_relation() routines in the relation oracle > and folding routines currently return void. They are called when there > is a relation to register and there has not been a need for feedback on > whether one was registered or not. > > The patch which caused this PR recognized that and on-demand calculation > of something in the middle of the IL may not have access to relations > which are not yet registered. When that relation is added later > during the DOM walk, and then the statement encountered again, the > original cached version is used and any benefit of the now known > relation is lost. > > This was resolved by updating the timestamp of the 2 ssa-names in the > relation when it is registered. When a statement using those names is > re-examined, the use timestamp will be newer than the definition and the > statement will be recalculated with the relation available. > > The problem shown here is a cycle of PHIs feeding each other... and each > one adding a relation potentially consumed by the other. This forces the > other to be recalculated. This was done whether a relation was actually > added or not. If no new relation is added, we should not update the > timestamps as there is no need to recalculate. > > This patch changes the record() and register_relation() methods in the > both the relation oracle and fold_using_range classes . These routines > now return TRUE if a new relation was added, and FALSE otherwise. The > timestamps are only updated now if TRUE is returned. > > In order for the debugging output to make sense, its been tweaked to > only print that a relation is registered, not that an attempt was being > made. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK?
One minor suggestion. Mention in comments before register_relation's that false means nothing changed. Likewise for add_partial_equiv and equiv_oracle::record and the others. Otherwise looks good to me but I can't approve it. Thanks, Andrew > > Andrew >
