On Thu, Mar 15, 2012 at 12:57 PM, Shin-Ming Liu <shinm...@gmail.com> wrote:
> 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.
>
Thanks for the good suggestion, we will make more careful test and approve
approach. for the pair of
SOME_EXPR
STID XXX
COND_EXPR
FALSEBR
* we will improve to untouch SOME EXPR.
*The simpilification of SOME_EXPR to CONST will be checked first, only
when it can be simplified, we continue
*The CONST proped into COND_EXPR will be then checked, only when proped
COND_EXPR can be simplified to OTHER CONST, we will make change, otherwise,
COND_EXPR unmodified.
Thanks again.
Regards
Gang
>
> 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
>
>
------------------------------------------------------------------------------
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
