hi, sun.
Before if_conv(opt_cfg.cxx), the wn is like as followed.
IF {line: 0} {freq: 0, ln: 0, col: 0}
F8F8LDID 75 <1,7,.preg_F8> T<11,.predef_F8,4> # <preg>
F8F8LDID 76 <1,7,.preg_F8> T<11,.predef_F8,4> # lpre_cst
I4F8LE
THEN
BLOCK {line: 0} {freq: 0, ln: 0, col: 0}
F8F8LDID 77 <1,7,.preg_F8> T<11,.predef_F8,4> # lpre_cst
F8STID 75 <1,7,.preg_F8> T<11,.predef_F8,4> # <preg> {line: 11} {freq: 0,
ln: 11, col: 0}
END_BLOCK
ELSE
BLOCK {line: 0} {freq: 0, ln: 0, col: 0}
END_BLOCK
END_IF
after add_one_if_stmt, it is converted to
F8F8LDID 75 <st 1793> T<11,.predef_F8,4>
F8F8LDID 76 <st 1793> T<11,.predef_F8,4>
I4F8LE
FALSEBR L2050 {line: 0} {freq: 0, ln: 0, col: 0}
---- BB4 (RPO 4) (GOTO) (e) LINE 0 (rid_id:0) (flag:7)
Preds:3
Succs:6
Fallthrough: 5
Next : BB5
Prev : BB3
dom_dfs_id(0), dom_dfs_last(0)
pdom_dfs_id(0), pdom_dfs_last(0)
F8F8LDID 77 <st 1793> T<11,.predef_F8,4>
F8STID 75 <st 1793> T<11,.predef_F8,4> {line: 11} {freq: 0, ln: 11, col: 0}
---- BB5 (RPO 5) (Lab2050) (GOTO) (e) LINE 0 (rid_id:0) (flag:7)
Preds:3
Succs:6
Fallthrough: 6
Next : BB6
Prev : BB4
dom_dfs_id(0), dom_dfs_last(0)
pdom_dfs_id(0), pdom_dfs_last(0)
And BB5 is the empty BB with label2050 map.
2010/8/31 Sun Chan <sun.c...@gmail.com>
> 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
> >
> >
>
--
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
