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
>> >> >
>> >
>> >
>
>
------------------------------------------------------------------------------
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
