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), Zdenek
