Hi, > > I would disagree on that. Whether a final value replacement is > > profitable or not largely depends on whether it makes further > > optimization of the loop possible or not; this makes it difficult > > to find a good cost model. I think undoing FVR is a good approach > > to solve this problem (unfortunately, the proposed implementation > > does not work), > > Ok, fair enough. Ideally we would then be able to retain the PHI nodes > and somehow record an equivalency in the IL from which we later could > remove either of the definitions. Something like > > def_1 = PHI < ... > > > def_2 = compute > > def_3 = EQUIV <def_1, def_2> > (def_3 = ASSERT_EXPR <def_2, def_2 == def_1>?) > > much similar to REG_EQUAL notes. This means that both def_1 and def_2 > are conditionally dead if the EQUIV is the only remaining use. > > No idea if this is feasible and useful enough in general though. > > Do you remember what kind of missed optimizations you saw (apart from > missed dead loop removal)?
vectorization and linear loop transformations did not like values used outside of the loop; I am not sure whether (our implementation of) graphite handles them or not, Zdenek
