This is complete now.  Go ahead with the commit.

Fred

On 04/20/2011 02:38 AM, Jian-Xin Lai wrote:
Yes, since my test case don't cover the bit field, I missed the other two places. Here comes the new patch. Could you please review it again? Thank you very much.

Index: osprey/be/opt/opt_revise_ssa.cxx
===================================================================
--- osprey/be/opt/opt_revise_ssa.cxx    (revision 3526)
+++ osprey/be/opt/opt_revise_ssa.cxx    (working copy)
@@ -269,6 +269,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);
@@ -389,6 +390,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);
@@ -483,6 +485,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 +595,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);


2011/4/20 Fred Chow <frdc...@gmail.com <mailto:frdc...@gmail.com>>

    This same fix was in the PathScale 3.2 beta source.  But there are
    4 places in that file that need this addition.  I see you only
    have covered two places.

    Fred


    On 04/18/2011 04:32 AM, Jian-Xin Lai 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  
<mailto: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

Reply via email to