I have a whole build for the linux kernel(the intensive using of ASM
statements)
We find
428777 tries for copy propragation for vars inside ASM_INPUT, in 3845 files
, 28609 pus
12560 successfuly copy proped in 1374 files, 3060 pus
The total build time in XEON x5570(2.93G, 24020M memory) workstation,
single threaded make , debug build compiler, O2 level, default .config(all
drivers and modules)
is 6h57m13s, i.e, no obvious increase in build time. The previouslys are
typically using at 6h50m or so for a whole build. We should also consider
the time spent on the IO dump for the debug purpose.
We believe the patch does not introduce obviously performance regression,
and we do see there are more copyprops in the build.
Regards
Gang
On Sat, Jan 7, 2012 at 9:26 PM, Sun Chan <sun.c...@gmail.com> wrote:
> 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
