I'm not convinced this is the right fix. I don't even know there is a
correct fix. The code currently is conservative, granted. OTOH, try a
few more examples where the *(p+n) varies, where n is 1, 2, 3, .....
Sun
On Mon, Apr 18, 2011 at 7:32 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
> Hi,
>
> Can a gate keeper review the patch to remove unnecessary CHIs introduced by
> Lda-Indirect folding? Thank you very much.
>
> The case is like this:
> 1 int in[10];
> 2 voif foo(int i) {
> 3 int *p = in;
> 4 *p++ = i++;
> 5 *p++ = i++;
> 6 *p++ = i++;
> 7 *p++ = i++;
> ...
>
> After the Lda-Indirect folding, the HSSA IR is like below:
>>LINE 4___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>>OPR_STID I4 I4 sym16v65535 0 <u=0 cr67> b=E3 flags:0x2 pj2 Sid3
>> // in[0] = i
> chi <4/cr21/cr1 14/cr22/cr5 15 17 18 19 > 0x0x80e3090
>>LINE 5___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>> LDC U4 1 <u=8187 cr11> flags:0x0 b=-1
>> I4ADD <u=1 cr12> isop_flags:0xdc040 flags:0x1 b=E42
>>OPR_STID I4 I4 sym17v65535 4 <u=0 cr71> b=E4 flags:0x2 pj2 Sid4
>> // in[1] = i+1
> chi <4/cr32/cr21 14/cr33/cr22 15 16/cr72/cr67 18 19 > 0x0x80e3478
>>LINE 6___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>> LDC U4 2 <u=8191 cr54> flags:0x0 b=-1
>> I4ADD <u=1 cr55> isop_flags:0xdc040 flags:0x1 b=E47
>>OPR_STID I4 I4 sym18v65535 8 <u=0 cr75> b=E5 flags:0x2 pj2 Sid5
>> // in[2] = i+2
> chi <4/cr43/cr32 14/cr44/cr33 15 16/cr76/cr72 17/cr77/cr71 19 > 0x0x80f85b8
>>LINE 7___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>> LDC U4 3 <u=8191 cr56> flags:0x0 b=-1
>> I4ADD <u=1 cr57> isop_flags:0xdc040 flags:0x1 b=E53
>>OPR_STID I4 I4 sym19v65535 12 <u=0 cr79> b=E6 flags:0x2 pj2 Sid6 //
>> in[3] = i+3
> chi <4/cr51/cr43 14/cr52/cr44 15 16/cr80/cr76 17/cr81/cr77 18/cr82/cr75 >
> 0x0x80f8880
>
> We can find the CHIs in red are unnecessary. Here is the patch:
> Index: osprey/be/opt/opt_revise_ssa.cxx
> ===================================================================
> --- osprey/be/opt/opt_revise_ssa.cxx (revision 3556)
> +++ osprey/be/opt/opt_revise_ssa.cxx (working copy)
> @@ -483,6 +483,7 @@
> _symbols_to_revise->Union1D(idx);
> AUX_STAB_ENTRY *aux = _opt_stab->Aux_stab_entry(idx);
> aux->Points_to()->Set_expr_kind(EXPR_IS_ADDR);
> + aux->Points_to()->Set_ofst_kind(OFST_IS_FIXED);
> aux->Points_to()->Set_named();
>
> cr->Set_scalar_aux_id(idx);
> @@ -592,6 +593,7 @@
> _symbols_to_revise->Union1D(idx);
> AUX_STAB_ENTRY *aux = _opt_stab->Aux_stab_entry(idx);
> aux->Points_to()->Set_expr_kind(EXPR_IS_ADDR);
> + aux->Points_to()->Set_ofst_kind(OFST_IS_FIXED);
> aux->Points_to()->Set_named();
>
> lhs->Set_scalar_aux_id(idx);
>
> When we convert the Lda-Indirect to STID/LDID, new Aux symbols are created
> for the STID/LDID.
> In the original code, the OFST_IS_FIXED is not set and the alias manager
> will treat the new symbols are aliased.
>
> With this patch, the new CODEREP looks like below:
>>LINE 4___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>>OPR_STID I4 I4 sym16v65535 0 <u=0 cr67> b=E3 flags:0x2 pj2 Sid3
> chi <4/cr21/cr1 14/cr22/cr5 15 > 0x0x80e3090
>>LINE 5___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>> LDC U4 1 <u=8187 cr11> flags:0x0 b=-1
>> I4ADD <u=1 cr12> isop_flags:0xdc040 flags:0x1 b=E41
>>OPR_STID I4 I4 sym17v65535 4 <u=0 cr68> b=E4 flags:0x2 pj2 Sid4
> chi <4/cr32/cr21 14/cr33/cr22 15 > 0x0x80e3478
>>LINE 6___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>> LDC U4 2 <u=8191 cr54> flags:0x0 b=-1
>> I4ADD <u=1 cr55> isop_flags:0xdc040 flags:0x1 b=E44
>>OPR_STID I4 I4 sym18v65535 8 <u=0 cr69> b=E5 flags:0x2 pj2 Sid5
> chi <4/cr43/cr32 14/cr44/cr33 15 > 0x0x80f85b8
>>LINE 7___
>> LDID I4 I4 sym1v3 57 ty=402 <u=8189 cr7> flags:0x0 b=V35
>> LDC U4 3 <u=8191 cr56> flags:0x0 b=-1
>> I4ADD <u=1 cr57> isop_flags:0xdc040 flags:0x1 b=E47
>>OPR_STID I4 I4 sym19v65535 12 <u=0 cr70> b=E6 flags:0x2 pj2 Sid6
> chi <4/cr51/cr43 14/cr52/cr44 15 > 0x0x80f8880
>
>
> --
> Regards,
> Lai Jian-Xin
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
