empty bb is not wrong code. My question is, where did that empty bb come from? Sun
On Mon, Aug 30, 2010 at 7:21 PM, ruifen Shen <shenr...@gmail.com> wrote: > hi, mei. > As sun said that one should never produce wrong code in any stage. > I agree with your opinion. > > Another, If adding label_stmt in the front in an early pahse, it should be > cleared or merged if the label is useless in my view. > > hi, sun. > which block? rvi_emit? > > > > 2010/8/31 Sun Chan <sun.c...@gmail.com> >> >> 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 > > > > -- > 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
