[Open64-devel] A wopt epre/sr bug

[Jian-Xin Lai]

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.

[Yiran Wang]

It sounds like no way to update the alias information. In that case, it has
to be set to NULL.
For this specific case here, only the FSA information becomes invalid, I
think, and is there any way to ignore this part only?

Regards,
Yiran

Post by Jian-Xin Lai
Hi,
I found a wopt epre/sr bug existing in current open64 trunk.
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
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
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
https://lists.sourceforge.net/lists/listinfo/open64-devel

[Jian-Xin Lai]

I can only reset the pointer ver, not the ivar_occ to invalid the FSA on
this node.

Post by Yiran Wang
It sounds like no way to update the alias information. In that case, it
has to be set to NULL.
For this specific case here, only the FSA information becomes invalid, I
think, and is there any way to ignore this part only?
Regards,
Yiran

Post by Jian-Xin Lai
Hi,
I found a wopt epre/sr bug existing in current open64 trunk.
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
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
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
https://lists.sourceforge.net/lists/listinfo/open64-devel