Re: [Open64-devel] A wopt epre/sr bug

[Yiran W. <yir...@gm...>]

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

On Mon, Oct 13, 2014 at 8:11 AM, Jian-Xin Lai <la...@gm...> wrote:

> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>