I wondered why there is such a block though. Sun On Tue, Aug 31, 2010 at 3:23 AM, Ye, Mei <mei...@amd.com> wrote: > 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> > > 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> 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] >> 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] >> 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 >> 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
