Sun,
I have a new compile-time testing for whole kernel build, this time
we build on a new machine
with
Intel(R) Xeon(R) CPU E5310 @ 1.60GHz, 32190M Memory
Linux pluto 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008 x86_64
x86_64 x86_64 GNU/Linux
opt build compiler, single threaded build
the total compile time
before bug787 patch: 17017 secs
after bug787 patch: 16999 secs
with noise considered, we think the patch does not obviously increase the
compile time.
Any more questions please let us know. Thanks
Regards
Gang
On Wed, Jan 11, 2012 at 1:55 PM, Sun Chan <sun.c...@gmail.com> wrote:
> debug build compiler has so many assertions and verification checks
> that the total compile time is totally skewed.
> Sun
>
> On Wed, Jan 11, 2012 at 11:43 AM, Gang Yu <yugang...@gmail.com> wrote:
> > 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
> >> >> >
> >> >
> >> >
> >
> >
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
