I would like to add one more point:
We disable simplifier at -O0 to simplify the debugging at -O0. Any
simplification at -O0 should be justified carefully.
Shin
On Wed, Mar 14, 2012 at 9:48 PM, Sun Chan <sun.c...@gmail.com> wrote:
> Very good feedback. We did not design wopt.so to be called by cg.so,
> and we never wanted O0 or O1 to run wopt. This same issue has been
> argued multiple times in another product compiler elsewhere which I
> won't name. Frankly, it's a sloppy feature of gcc, imho.
> I would go with Ljx's suggestion of using vho to try deal with it.
> Sun
>
> On Wed, Mar 14, 2012 at 12:32 AM, Jian-Xin Lai <laij...@gmail.com> wrote:
> > Some comments:
> > 1. Link wopt.so into cg.so is bad. It breaks the modularization. Also,
> > the start time is increased at O0/O1 because wopt.so is loaded
> > unconditionally.
> > 2. It's not good to add this phase to CG since it's target
> > independent. Maybe you can try to add a new phase to be driver.
> > 3. For case of switch, it's not good to match the patterns to find the
> > candidates of constant. Maybe you can simplify the high level SCF in
> > VHO and split this work into 3 parts:
> > part1: simplify the high level SCF in VHO
> > part2: simplify the low level BR instructions in the new phase
> > part3: build the CFG and remove unreachable code.
> >
> > 2012/3/7 Gang Yu <yugang...@gmail.com>:
> >> Hi, list:
> >>
> >> We have a new design and implementation for fix the gcc incompatible
> >> issue, tracked as bug798,bug588,..., i,e. open64 unable to delete the
> >> unreachable code under O0 as gcc does.
> >>
> >> A typical case below:
> >>
> >> int defined_fun()
> >> {
> >> }
> >> int main()
> >> {
> >> int t;
> >> switch(sizeof(t))
> >> {
> >> case 1:
> >> undefined_fun2();
> >> break;
> >> case 4:
> >> defined_fun();
> >> break;
> >> case 8:
> >> undefined_fun3();
> >> default:
> >> undefined_fun();
> >> }
> >> return 0;
> >> }
> >> Previously, we have proposed invoking the wopt by a special preopt
> phase "q"
> >> which includes only copy-prop/DCE phases, however, this approach is not
> >> accepted due to
> >>
> >> *) it obviously increase the compile time due to the essetial,
> compile-time
> >> expensive components in WOPT. This is not acceptable by O0 users who are
> >> quite sensitive to the compile-time.
> >> *) Invoking wopt may cause some stmts losing the dwalf debug info, this
> is
> >> not acceptable by people intent to debug the program using "-O0 -g".
> >>
> >> After that, we have a detailed analysis on the O0 DCE problem, roughly,
> >> there are two Unreachable Code Elimination(UCE) cases to handle under O0
> >> 1) the if -then-else case:
> >> if (sizeof(type x) == A) {
> >> ...;
> >> } else if (sizeof(type y) == B) {
> >> ...;
> >> } else {
> >> ...
> >> }
> >> 2). the switch case : just like the above shown case.
> >>
> >> under O0, open64 can handle the case 1, this is because (sizeof(type x)
> ==
> >> A) can be whirl expressed and folded to
> >>
> >> INTCONST 0
> >> FALSEBR/TRUEBE
> >>
> >> so, unreachable branches then can be indirectly deleted by branch
> handling
> >> the case V_BR_NONE or V_BR_ALWAYS
> >>
> >> All we wanted is to handle the "switch-case", The new suggested way is
> to
> >> build CFG at the beginning of CG_Generate_Code, we do *special const
> >> propagation* and then *condition fold* to make the branch as
> >>
> >> U8INTCONST 4 (0x4)
> >> U8STID 0 <2,2,_temp__switch_index0> T<9,.predef_U8,8> {line: 1/10}
> >> U8U8LDID 0 <2,2,_temp__switch_index0> T<9,.predef_U8,8>
> >> U8INTCONST 4 (0x4)
> >> I4U8EQ
> >> U8INTCONST 4 be copy propagated to:
> >> U8U8LDID 0 <2,2,_temp__switch_index0> T<9,.predef_U8,8>
> >>
> >> Then
> >> U8INTCONST 4 (0x4)
> >> U8INTCONST 4 (0x4)
> >> I4U8EQ
> >> folded to
> >> INTCONST 1
> >> TRUEBR
> >>
> >> then let the branch expansion routine do things.
> >>
> >> We have some basic design rules:
> >> *) make things as simple as possible, the introduced procedure is only
> for
> >> gnu compatiblity and no intent to be optimisation. So, we only
> do limited
> >> const prop and expression fold, no real DCE or other changes to CFG.
> >> *) maxium leverage the current production modules, do *not* invent new
> >> things
> >> a). invoke the opt_cfg for CFG building
> >> b). port the OPT_RVI_EMIT for cfg emit and region handling.
> >>
> >> Attached is the patch, self checking the patch, we do not find the
> issues
> >> by preopt "q" phase, since,
> >> *) the only compile time expense is to build-up the CFG, then emit back,
> >> *) we only modify kids of (FALSE/TRUE) branch stmts, do not corrupt the
> >> dwalf info.
> >>
> >> Applying the patch, we build up the linux kernel using "-O0 -g".
> >>
> >> Would a gatekeeper please help review the patch? Thanks a lot.
> >>
> >>
> >> Regards
> >> Gang
> >>
> >>
> ------------------------------------------------------------------------------
> >> Virtualization & Cloud Management Using Capacity Planning
> >> Cloud computing makes use of virtualization - but cloud computing
> >> also focuses on allowing computing to be delivered as a service.
> >> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> >> _______________________________________________
> >> Open64-devel mailing list
> >> Open64-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>
> >
> >
> >
> > --
> > Regards,
> > Lai Jian-Xin
> >
> >
> ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Open64-devel mailing list
> > Open64-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
