On Wed, Oct 1, 2008 at 6:22 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > Hi, > >> > Based on the conversation in the thread at >> > http://gcc.gnu.org/ml/gcc/2008-03/msg00513.html , we've tried to get a >> > pass trying to undo final value replacement going. The initial >> > implementation was done by Pranav Bhandarkar when he was employed at >> > Azingo as part of work sponsored by Icera Semiconductor. I've been >> > trying to get this working with my private port over here. We intend >> > to contribute this back once our copyright assignments are sorted and >> > if this will be acceptable to all. I've been getting a few compile >> > time ICEs with this approach and haven't been able to resolve them >> > well enough yet. Whilst doing so, I wanted to check on the approach as >> > outlined below and ask if there's anything that we might have missed >> > or any problem that one can see with us going along these lines. >> > Thanks for your time and patience. >> >> Some quick comments. First, do you have a non-pseudo-code testcase >> that exposes the extra computations? Second, I think rather than >> trying to undo what SCEV const(!)-prop is doing adjust its cost >> model (maybe there isn't one) to not create the costly substitutions. > > 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)? Thanks, Richard.
