Re: The effects of closed loop SSA and Scalar Evolution Const Prop.

1 msg	gcc 4.2.3 : make: *** [bootstrap] Error 2
2 msg	minor mistake in http://gcc.gnu.org/gcc-4.3/cha...
15 msg	libtool for shared objects?
1 msg	aneurin chandras hammond griswold
1 msg	Adding new section attribute

The effects of closed loop SSA and Scalar Evolu...
\ Pranav Bhandarkar (11 Mar 2008)
. \ Zdenek Dvorak (11 Mar 2008)
. . \ Daniel Berlin (11 Mar 2008)

2 msg	howto run cross testings with help of translators
1 msg	gcc-4.1-20080310 is now available
6 msg	GNAT on SVN Trunk
2 msg	CRX and CR16 port maintainer
2 msg	New picoChip port and maintainers
11 msg	vectorizer default in 4.3.0 changes document mi...
2 msg	GCC 4.3.0-20080228 (powerpc-linux-gnuspe) ICE o...
10 msg	RTL definition
7 msg	Possible gcc-4.3 regression wrt bootstrapping t...
19 msg	[tuples] gimple_assign_subcode for GIMPLE_SINGL...
3 msg	Combine repeats matching on insn pairs and will...
1 msg	gcc-4.4-20080307 is now available
1 msg	Need link ln -s ../lib64/libgomp.spec libgomp.s...
15 msg	RFC: Idea for code size reduction

Subject:	Re: The effects of closed loop SSA and Scalar Evolution Const Prop.
Group:	Gcc
From:	Daniel Berlin
Date:	11 Mar 2008

On Tue, Mar 11, 2008 at 9:41 AM, Zdenek Dvorak <rakdver> 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.