It passes at -O0 and at -O1. Fails at -O2. Regards, Shivaram
-----Original Message----- From: Sun Chan [mailto:sun.c...@gmail.com] Sent: Tuesday, January 10, 2012 6:00 AM To: Ye, Mei Cc: open64-devel Subject: Re: [Open64-devel] Review request for fix bug787[WOPT] I wonder what the behavior at O0 for this bug? Sun On Tue, Jan 10, 2012 at 8:28 AM, Sun Chan <sun.c...@gmail.com> wrote: > thx for pointing this out, it could cause problem for automatic bug triaging. > Sun > > On Tue, Jan 10, 2012 at 1:34 AM, Ye, Mei <mei...@amd.com> wrote: >> I don't have objection to this fix. But this bug exposes a design problem >> in DCE, i.e., >> DCE can't handle a situation where copy prop is disabled upstream. >> >> -Mei >> >> -----Original Message----- >> From: Sun Chan [mailto:sun.c...@gmail.com] >> Sent: Friday, January 06, 2012 9:55 PM >> To: Gang Yu >> Cc: open64-devel >> Subject: Re: [Open64-devel] Review request for fix bug787[WOPT] >> >> this fix looks better. i am still a bit worry about regressions >> (performance). Have you checked perf regression with this change? >> Sun >> >> On Sat, Jan 7, 2012 at 1:36 PM, Gang Yu <yugang...@gmail.com> wrote: >>> Hi, >>> >>> I have a new fix for the bug787, the cut-down case from Rao(thanks) is as >>> follows: >>> >>> extern int main(int argc) >>> { >>> int res1; >>> int val0,val1; >>> val1=100; >>> if(1) >>> { >>> asm("bswapl %0" : "=r" (val0) : "0" (val1)); >>> res1=val0; >>> } >>> val0=res1; >>> asm("bswapl %0" : "=r" (val1) : "0" (val0)); >>> } /* main */ >>> analysis: >>> >>> Current open64 disallows copy propagation into ASM_INPUT for the var and >>> ivar cases, this is reasonable since some constraints do only allow the >>> parameter in specific form. >>> >>> If we fix following Rao's suggested way, i.e, mark some identity assignment >>> undeletable for DCE, then we need special marking work for the identity >>> assignment. >>> >>> a sound way as RAO suggested is say if the LHS of the identity assignment >>> has flag CR_DONT_PROP, we disable deleting this identiy assign. However, >>> this triggers the problem that other identity assign also undeletable only >>> if its LHS has CR_DONT_PROP, so bug882 thrown out and it is hard to patch >>> again for this special handling, this changes the default verifycation >>> and DCE behavior. >>> >>> My suggested way is that we try propagate to a var inside ASM_INPUT, if the >>> propagated expr is also a var, we allow this propagation. in the above case >>> >>>>LINE 13___ >>>> LDID I4 I4 sym5v3 0 ty=402 <u=2 cr13> flags:0x8 b=-1 #res1 >>>>OPR_STID I4 I4 sym4v4 0 <u=0 cr15> b=-1 flags:0x2 pj2 Sid-1 >>> chi <> 0x0x80e1e40 >>>>LINE 14___ >>> mu<9/cr14 > >>>> LDID I4 I4 sym4v4 0 ty=402 <u=0 cr15> flags:0x0 b=-1 #val0 >>>> ASM_INPUT opnd:1 <u=0 cr16> isop_flags:0xc0000 flags:0x0 b=E1 >>>> ASM_STMT <u=0 cr17> isop_flags:0xc0000 flags:0x0 b=-1 >>>>OPR_ASM_STMT b=-1 flags:0x2 pj2 Sid-1 >>> sym5v3 is propagated into OPR_ASMINPUT. >>> >>> The patch below: >>> >>> --- a/osprey/be/opt/opt_prop.cxx >>> +++ b/osprey/be/opt/opt_prop.cxx >>> @@ -1504,9 +1504,23 @@ COPYPROP::Copy_propagate_cr(CODEREP *x, BB_NODE >>> *curbb, >>> expr = Copy_propagate_cr(x->Opnd(i), curbb, inside_cse, in_array); >>> else { >>> // OSP_384 >>> - if(opr == OPR_ASM_INPUT) >>> - x->Opnd(i)->Set_flag(CF_DONT_PROP); >>> - expr = NULL; >>> + if(opr == OPR_ASM_INPUT) { >>> + // open64.net bug787. Try propagate for VAR first, if the >>> propagated expr is the same >>> + // kind to the original one,i.e, also a VAR. we allow this >>> propagation. otherwise, disable it. >>> + if ( x->Opnd(i)->Kind() == CK_VAR ) { >>> + CODEREP *possible_prop = Copy_propagate_cr(x->Opnd(i), curbb, >>> inside_cse, in_array); >>> + if (possible_prop && possible_prop->Kind() == >>> x->Opnd(i)->Kind()) >>> + expr = possible_prop; >>> + else { >>> + x->Opnd(i)->Set_flag(CF_DONT_PROP); >>> + expr = NULL; >>> + } >>> + } >>> + else { >>> + x->Opnd(i)->Set_flag(CF_DONT_PROP); >>> + expr = NULL; >>> + } >>> + } >>> } >>> #else >>> please gatekeeper help a review >>> >>> Thanks. >>> >>> Regards >>> Gang >>> >>> ------------------------------------------------------------------------------ >>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >>> infrastructure or vast IT resources to deliver seamless, secure access to >>> virtual desktops. With this all-in-one solution, easily deploy virtual >>> desktops for less than the cost of PCs and save 60% on VDI infrastructure >>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >>> _______________________________________________ >>> Open64-devel mailing list >>> Open64-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >> >> ------------------------------------------------------------------------------ >> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >> infrastructure or vast IT resources to deliver seamless, secure access to >> virtual desktops. With this all-in-one solution, easily deploy virtual >> desktops for less than the cost of PCs and save 60% on VDI infrastructure >> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox >> _______________________________________________ >> Open64-devel mailing list >> Open64-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/open64-devel >> >> ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
