Hi, > 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.
sorry for the leftover comment -- there used to be a test for the cost of the computation, but it caused so many (missed optimization) problems that I removed it in the end, Zdenek
