On Wed, Oct 1, 2008 at 3:59 PM, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Wed, Oct 1, 2008 at 3:22 PM, Ramana Radhakrishnan <[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.
Indeed the comment on scev_const_prop says "Also perform final value replacement in loops, in case the replacement expressions are cheap." but no such check for cheapness is done. Whatever cost model we add we need to make sure to not disable empty loop removal - that is, loops that only care for the final value of their induction variable. A sensible simple cost model is that the replacement is either a constant, a SSA_NAME or an expression of the form CST * name + CST (which may be a common thing). In your testcase there are even divisions inserted. I guess the empty-loop removal interaction makes fixing this one harder, but trying to record things to undo this transformation doesn't look right either. Richard.
