The lda-indirect can only be folded when the offset is constant. In that
case, it's safe to set the POINTS_TO to be OFST_IS_FIXED.
2011/4/18 Sun Chan <sun.c...@gmail.com>
> 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
> >
> >
>
--
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
