Hi,
I found a wopt epre/sr bug existing in current open64 trunk.
Here is a case:
p[0] = expr1;
while (1) {
temp = p[0]; // A
stmts (use of temp)
if (...)
break;
p[4] = expr2; // B
p += 4; // C
}
In FSA phase, the points-to for ILOAD in stmt A is set to
"Pointer_is_named_symbol" and the Pointer is "p", Pointer_ver is the index
of the VSE entry of p. For stmt A and B, they are not aliased because they
have the same "pointer" and different offset.
After epre/sr, A is eliminated and a new computation is inserted into the
end of loop body:
temp = expr1;
p[0] = temp;
while (1) {
stmts (use of temp)
if (...)
break;
p[4] = expr2; // B
p += 4; // C
temp = p[0]; // A'
}
The IVAR used in A' was created from A. When rehashing the new IVAR, the
Ivar_occ is also copied in Rehash_tree_rec in opt_expr.cxx:
196 if (newcr->Ivar_occ() != NULL)
197 newcr->Set_ivar_occ(CXX_NEW(OCC_TAB_ENTRY(*newcr->Ivar_occ()),
198 htable->Sym()->Occ_pool()));
199 else
200 newcr->Set_ivar_occ(NULL);
Now both A' and A have the same Ivar_occ. Based on the
Aliased_Indirect_Rule, the new ILOAD in A' is still not aliased with the
ISTORE B. In later CG phase, the scheduler will reorder A' and B.
Here is the question, it looks like it's illegal to copy the Ivar_occ from
an existing CR to a new CR considering the case of the Ilod/Istr base is
changed. But how can we update the Ivar_occ with precise points-to info?
The VSE table has been destroyed when WHIRL is converted into CODEMAP.
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
