Bug 14562 : copyrename & PRE

[Andrew MacLeod]

copyrename doesnt *appear* to be doing anything wrong. 

The original program had:

  T.1<D1071>_29 = k<D1063>_2 - h<D1062>_5;
  T.2<D1072>_30 = T.1<D1071>_29 * 4;

and copy rename decided that version _29 would be better off as a 'k',
so it produces:

  k<D1063>_29 = k<D1063>_2 - h<D1062>_5;
  T.2<D1072>_30 = k<D1063>_29 * 4;

and PRE decides that worth doing something with:

  k<D1063>_29 = k<D1063>_2 - h<D1062>_5;
  pretmp.18<D1129>_50 = k<D1063>_29 * 4;
  T.2<D1072>_30 = pretmp.18<D1129>_50;

In the -fno-tree-copyrename version, PRE doesn't touch T.1_29... but it
does when it becomes 'k'.
 
Do we have magic rules about PARMs where they aren't allowed to be
assign to? 'k' is a PARM, and PRE appears to be make an assumption about
it. Up until now we haven't really been seeing a DEF of a PARM, its
always been into a temp variable.

Is there something about PARMs that I ought not allow a rename on the
LHS to a PARM, or is PRE making a bad assumption?

Andrew