This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Bug 14562 : copyrename & PRE
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: gcc-bugs <gcc-bugs at gcc dot gnu dot org>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, Jeff Law <law at redhat dot com>, RichardHenderson <rth at redhat dot com>
- Date: 15 Mar 2004 10:36:50 -0500
- Subject: Bug 14562 : copyrename & PRE
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