Author: shivaram
Date: 2011-10-16 06:12:14 -0400 (Sun, 16 Oct 2011)
New Revision: 3764
Modified:
trunk/osprey/be/opt/opt_dce.cxx
Log:
Fix for bug#787. Removal of identity assignment statements(i=i) is
prevented if lhs is not propagatable.
CR by Ye,Mei and Gautam
Modified: trunk/osprey/be/opt/opt_dce.cxx
===================================================================
--- trunk/osprey/be/opt/opt_dce.cxx 2011-10-14 08:12:52 UTC (rev 3763)
+++ trunk/osprey/be/opt/opt_dce.cxx 2011-10-16 10:12:14 UTC (rev 3764)
@@ -2149,7 +2149,8 @@
if (OPERATOR_is_scalar_store (opr) &&
Enable_identity_removal() &&
- stmt->Is_identity_assignment_removable()) // if COPYPROP assumes the
stmt is deleted
+ stmt->Is_identity_assignment_removable() &&
+ !(stmt->Lhs()->Flags() & CF_DONT_PROP)) // if COPYPROP assumes the stmt
is deleted
return FALSE;
// statements with zero-version chi nodes are required
@@ -3262,7 +3263,8 @@
if (OPERATOR_is_scalar_store (opr) &&
Enable_identity_removal() &&
- stmt->Is_identity_assignment_removable()) {
+ stmt->Is_identity_assignment_removable() &&
+ !(stmt->Lhs()->Flags() & CF_DONT_PROP)) {
// process the rhs expression, if any
CODEREP *rhs = stmt->Rhs();
if ( rhs != NULL ) {
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
