Hello Ruifen,
It looks like RVI_EMIT assumes an empty block should not be a branch target.
My opinion is before "Emit_bb" is called, we should have a pass to delete empty
blocks and delete/insert label stmts.
If you refer to "be/opt/opt_htable_emit.cxx", search for "Fix 592011",
"CFG::Delete_empty_BB" is called to do similar pre-processing.
Adding a label stmt up in the front in an early phase can introduce useless
labels. Though it probably doesn't hurt if later phases can clean it up.
-Mei
________________________________
From: ruifen Shen [mailto:shenr...@gmail.com]
Sent: Sunday, August 29, 2010 6:31 PM
To: Sun Chan; Ye, Mei
Cc: open64-devel
Subject: Re: [Open64-devel] One bug in add_one_if_stmt, Can gatekeeper review
this patch? Thx very much
hi, mei & sun.
Thanks very much for your review. I am sorry for the later reply as I am on
weekend.
Attached Please find the souce file(a.c) and the trace file with flags (slcc
a.c -Wb,-trLOW,-tt25:0xffffffff,-tt26:0xffffffff).
we can see that the lab2050 is mapped with BB5 at line 12104 of a.t. But after
the RVI_EMIT (tansform back to whirl tree), the mapping is missing.
Add label_stmt at RVI_EMIT? I do not think it is a good method.
Please help to analysis that. Thanks very much.
2010/8/28 Sun Chan <sun.c...@gmail.com<mailto:sun.c...@gmail.com>>
Mei,
I think you are right. The assertion about RID is a hint of something
else wrong (RID stands for region id).
Sun
On Sat, Aug 28, 2010 at 12:36 AM, Ye, Mei
<mei...@amd.com<mailto:mei...@amd.com>> wrote:
> My guess is that by adding a label statement you may have prevented the
> elimination of an empty block or something similar which then preserves the
> label-BB map and thus avoids the assertion.
>
>
>
> -Mei
>
>
>
> ________________________________
>
> From: Ye, Mei [mailto:mei...@amd.com<mailto:mei...@amd.com>]
> Sent: Friday, August 27, 2010 9:25 AM
> To: ruifen Shen; open64-devel
> Subject: Re: [Open64-devel] One bug in add_one_if_stmt, Can gatekeeper
> review this patch? Thx very much
>
>
>
> Hello Ruifen
>
>
>
> I am not convinced that a label statement is needed here.
>
> It is likely that somewhere downstream after some sort of transformations a
> different bug misses a mapping between a label and a BB which then triggers
> the assertion.
>
>
>
> -Mei
>
>
>
> ________________________________
>
> From: ruifen Shen [mailto:shenr...@gmail.com<mailto:shenr...@gmail.com>]
> Sent: Friday, August 27, 2010 2:36 AM
> To: open64-devel
> Subject: [Open64-devel] One bug in add_one_if_stmt, Can gatekeeper review
> this patch? Thx very much
>
>
>
> hi, all.
>
>
>
> We found One bug in add_one_if_stmt (opt_cfg.cxx). Can gatekeeper give a
> reivew? Thanks very much.
>
>
>
> When create the else_bb, it just create label_map without label_stmt.
>
> Then in the later phase. if there is check_label for BB(such as dce,
> reconstruction-cfg), the label_stmt will be added.
>
> Othere wise, the label will be missed at cg phase. Assertion will be
> reported like followed.
>
>
>
> ### Assertion failure at line 5392 of
> /home/test/regression/open64-SL/osprey/be/cg/whirl2ops.cxx:
> ### Compiler Error in file a.c during Code_Expansion phase:
> ### RID == NULL, label 2050 doesn't have a matching target
>
>
>
> I would like to fix the bug as followed.
>
>
>
> Index: opt_cfg.cxx
> ===================================================================
> --- opt_cfg.cxx (revision 3323)
> +++ opt_cfg.cxx (working copy)
> @@ -2298,8 +2298,7 @@
> CFG::Add_one_if_stmt( WN *wn, END_BLOCK *ends_bb )
> {
> // create, but do not connect, the "else" block
> - BB_NODE *else_bb = Create_bb();
> - Append_label_map(Alloc_label(), else_bb);
> + BB_NODE *else_bb = Create_labelled_bb();
>
> // create if bb
> WN *end_cond = WN_CreateFalsebr(else_bb->Labnam(), WN_if_test(wn));
>
>
>
> --
> Best Regards.
>
> Shen Ruifen
>
> tel: 010-51266989-226
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net<mailto:Open64-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
--
Best Regards.
Shen Ruifen
tel: 010-51266989-226
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
