Initial reaction: this approach is much better fit the design flow of
the entire compiler.
Sun
On Wed, Mar 7, 2012 at 9:17 PM, Gang Yu <yugang...@gmail.com> wrote:
> 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
>
------------------------------------------------------------------------------
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
