copy prop is not always a win. I'd like to see some performance
testing. If possible, compile time testing. it is known to cause
longer compile time also (it is basically a n^^2 algo
Sun
On Sat, Jan 7, 2012 at 5:28 PM, Gang Yu <yugang...@gmail.com> wrote:
> Thanks for the review.
>
> The new patch introduces more copy-props in the code. so, personally I think
> if it will not introduce performance regression.
>
> We test the whole kernel build, besides fix bug787, it does not introduce
> new failures.
>
> Regards
> Gang
>
>
> On Sat, Jan 7, 2012 at 1:54 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>
>> 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
