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
bug798_new.patch
Description: Binary data
------------------------------------------------------------------------------ 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
