On Tue, Mar 11, 2008 at 9:41 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> > Now tree scalar evolution goes over PHI nodes and realises that
> > aligned_src_35 has a scalar evolution {aligned_src_22 + 16, +, 16}_1)
> > where aligned_src_22 is
> > (const long int *) src0_12(D) i.e the original src pointer. Therefore
> > to calculate aligned_src_62 before the second loop computations are
> > introduced based on aligned_src_22.
> >
> > My question is, shouldnt scalar evolution ignore PHI nodes with one
> > argument (implying a copy)
>
> no, it should not (scev_cprop only deals with phi nodes with one
> argument).
>
>
> > or If not atleast pay heed to the cost of
> > additional computations introduced.
>
> Yes, it should, in some form; however, it would probably not help this
> testcase anyway, as computing x + 16 * y is too cheap. Final value
> replacement is often profitable even if it introduces some additional
> computation, as performing it may make other loop optimizations
> (vectorization, loop nest optimizations) possible.
>
> One solution would be to add a pass that would replace the computations
> with final values in a loop, undoing this transformation, after the
> mentioned optimizations are performed (FRE could do this if value
> numbering were strong enough, but that might not be feasible).
SCCVN could certainly be taught to look at the SCEV values and
incorporate them into value numbers (IE we fallback to saying a name
is equivalent to its scalar evolution rather than itself, or
something). I looked into this once, and it got quite expensive
because SCEV is not particularly fast.
