Re: query regarding adding a pass to undo final value replacement.

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hi,

> On Wed, Oct 1, 2008 at 3:59 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> > On Wed, Oct 1, 2008 at 3:22 PM, Ramana Radhakrishnan <ramana.r@gmail.com> 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