Feng,
Is it possible to reduce the test case weave.i to a few number of lines to
demonstrate the problem?
Shin
On Mon, Feb 7, 2011 at 11:23 AM, Feng Zhou <fengzho...@gmail.com> wrote:
> Sun,
>
> For bug #707, the symptom is compile-time assertion:
> ### Assertion failure at line 921 of
>
> /wsp/fzhou/open64/dbg-objdir/osprey/../../open64/osprey/be/opt/opt_verify.cxx:
> ### Compiler Error in file test.c during Global Optimization -- Verify
> Live-Range phase:
> ### sym8v2(cr13) live range overlapped with cur_version sym8v0(cr40)
> in bb12 line 19
>
> This happens right after creating codemap and there are only four
> optimizations/phases before it: DSE, Re-association, Find Zero
> Version, Create Codemap. By disabling the phases in the reverse order
> of their invocation, I first pinned down to DSE phase. Here is the
> partial result after Create_CODEMAP:
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> (gdb) p Dump_cfg()
> ---- BB3 (RPO 3) (LOGIF) (e) LINE 15 (rid_id:0) (flag:207)
> >LINE 15___
> > LDC U4 0 <u=7 cr24> flags:0x0 b=-1
> >OPR_STID I4 I4 sym3v4 0 <u=8191 cr31> b=-1 flags:0x2 pj2 Sid-1
> chi <10/cr32/cr17 > 0x0x8108678
> >LINE 16___
> > LDC U4 33 <u=1 cr33> flags:0x0 b=-1
> > LDA U8 sym5 0 <u=2 cr34> flags:0x0 b=-1 #buffer
> > LDID I4 I8 sym4v2 0 ty=402 <u=2 cr7> flags:0x10 b=-1 #limit
> > U8ADD <u=2 cr35> isop_flags:0x0 flags:0x0 b=-1
> >OPR_ISTORE U1 0 <u=0 cr36> b=-1 flags:0x2 pj2 Sid-1
> chi <5/cr37/cr9 8/cr40/cr13 9 10/cr38/cr32 > 0x0x8108728
> <==== Notice the CHI node for 8/cr40/cr13 is live (since
> Dump_cfg only print live CHI node)
> >LINE 17___
> > LDID U1 U4 sym8v0 0 ty=600 <u=2 cr40> flags:0x150 b=-1 #buffer
> <==== This wn was an ILOAD before Create_CODEMAP
> > LDC U4 32 <u=4 cr41> flags:0x0 b=-1
> > I4U4EQ <u=1 cr42> isop_flags:0x0 flags:0x0 b=-1
> >OPR_TRUEBR 6146 b=-1 flags:0x2 pj2 Sid-1
> ---- BB12 (RPO 12) (Lab770) (LOGIF) (e) LINE 17 (rid_id:0) (flag:207)
> >LINE 17___
> >OPR_LABEL 770 b=-1 flags:0x2 pj2 Sid-1
> >LINE 19___
> > LDC U4 32 <u=4 cr41> flags:0x0 b=-1
> > LDA U8 sym5 0 <u=2 cr34> flags:0x0 b=-1 #buffer
> > LDID I4 I8 sym4v2 0 ty=402 <u=2 cr7> flags:0x10 b=-1 #limit
> > U8ADD <u=2 cr35> isop_flags:0x0 flags:0x0 b=-1
> >OPR_ISTORE U1 0 <u=0 cr57> b=-1 flags:0x2 pj2 Sid-1
> chi <5/cr58/cr37 8/cr59/cr13 9/cr60/cr15 10/cr61/cr56 > 0x0x8108f78
> <===== Notice the CHI node 8/cr59/cr13, this together with CHI
> node above caused the assertion, since BB3 dom BB12
> >LINE 20___
> > LDID I4 I8 sym4v2 0 ty=402 <u=2 cr7> flags:0x10 b=-1 #limit
> > I4I8CVT <u=2 cr62> isop_flags:0x0 flags:0x0 b=-1
> > LDC U4 1 <u=2 cr45> flags:0x0 b=-1
> > I4I4GT <u=1 cr63> isop_flags:0x0 flags:0x0 b=-1
> >OPR_FALSEBR 7426 b=-1 flags:0x2 pj2 Sid-1
>
> (gdb) p comp_unit->_htable->Print(stderr)
> ----aux_id 5 Type:4 ST:buffer
> *cr58 b=-1 >LDID sym5v5 0 ty=3804 <u=0 cr58> flags:0x12 0x0x8108ff8
> *cr37 b=-1 >LDID sym5v4 0 ty=3804 <u=0 cr37> flags:0x12 0x0x8108850
> *cr27 b=-1 >LDID sym5v3 0 ty=3804 <u=0 cr27> flags:0xa 0x0x8108558
> *cr10 b=-1 >LDID sym5v0 0 ty=3804 <u=0 cr10> (no-def) flags:0x82
> 0x0x8108118
> *cr9 b=-1 >LDID sym5v2 0 ty=3804 <u=0 cr9> flags:0x12 0x0x81080e0
>
> ----aux_id 8 Type:2 ST:buffer
> cr59 b=-1 >LDID U1 U4 sym8v5 0 ty=600 <u=1 cr59> flags:0x12 0x0x8109030
> cr40 b=-1 >LDID U1 U4 sym8v0 0 ty=600 <u=2 cr40> flags:0x150 0x0x8108938
> *cr28 b=-1 >LDID U1 U4 sym8v3 0 ty=802 <u=0 cr28> flags:0xa 0x0x8108590
> *cr14 b=-1 >LDID U1 U4 sym8v0 0 ty=802 <u=0 cr14> flags:0x82 0x0x81081f8
> *cr13 b=-1 >LDID U1 U4 sym8v2 0 ty=802 <u=0 cr13> flags:0x12 0x0x81081c0
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Right before Create_CODEMAP and after Find_Zero_Version, the SSA looks
> as follows (in Create_CODEMAP, sym8v30 is mapped to sym8v0 cr40, while
> sym8v19 is mapped to sym8v2 cr13):
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> (gdb) p comp_unit->Ssa()->Print()
> U4INTCONST 33 (0x21)
> I8I4LDID 0 <st 15> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U1ISTORE 0 T<58,anon_ptr.,8> {line: 1/16} {freq: 0, ln: 16, col: 0}
> sym5v29 <- chi( sym5v16 ) LIVE
> sym8v30 <- chi( sym8v19 ) NOT LIVE
> <== Note this CHI is not Live at this point, but will be
> resurrected by Create_CODEMAP due to mu[ sym5v29 ]
> sym9v31 <- chi( sym9v20 ) NOT LIVE
> sym10v32 <- chi( sym10v27 ) LIVE
> I8I4LDID 0 <st 28> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U4U1ILOAD 0 T<6,.predef_U1,1> T<58,anon_ptr.,8>
> mu[ sym5v29 ]
> U4INTCONST 32 (0x20)
> I4U4EQ
> TRUEBR L6146 {line: 1/17} {freq: 0, ln: 17, col: 0}
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Now, going back to the SSA right after DSE:
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> (gdb) p comp_unit->Ssa()->Print()
> U4INTCONST 33 (0x21)
> I8I4LDID 0 <st 15> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U1ISTORE 0 T<58,anon_ptr.,8> {line: 1/16} {freq: 0, ln: 16, col: 0}
> sym5v29 <- chi( sym5v16 ) LIVE
> sym8v30 <- chi( sym8v19 ) NOT LIVE
> <===== the CHI node that caused this bug
> sym9v31 <- chi( sym9v20 ) NOT LIVE
> sym10v32 <- chi( sym10v27 ) LIVE
> I8I4LDID 0 <st 28> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U4U1ILOAD 0 T<6,.predef_U1,1> T<58,anon_ptr.,8>
> mu[ sym5v29 ]
> U4INTCONST 32 (0x20)
> I4U4EQ
> TRUEBR L6146 {line: 1/17} {freq: 0, ln: 17, col: 0}
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> //// deleted dump in between for ease of reading
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> BB11:
> sym3v37 <- phi(sym3v28,sym3v36)
> sym10v38 <- phi(sym10v32,sym10v35)
> LABEL L5890 0 {line: 1/17} {freq: 0, ln: 17, col: 0}
> LABEL L770 0 {line: 1/17} {freq: 0, ln: 17, col: 0}
> U4INTCONST 32 (0x20)
> I8I4LDID 0 <st 15> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U1ISTORE 0 T<58,anon_ptr.,8> {line: 1/19} {freq: 0, ln: 19, col: 0}
> sym5v39 <- chi( sym5v29 ) LIVE
> sym8v40 <- chi( sym8v19 ) LIVE
> <=== source operand is sym8v19, this is the result of DSE
> sym9v41 <- chi( sym9v20 ) LIVE
> sym10v42 <- chi( sym10v38 ) LIVE
> I4I4LDID 0 <st 15> T<4,.predef_I4,4>
> I4INTCONST 1 (0x1)
> I4I4GT
> FALSEBR L7426 {line: 1/20} {freq: 0, ln: 20, col: 0}
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Here is the SSA right before DSE as a corollary of the above statement:
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> (gdb) p comp_unit->Ssa()->Print()
> U4INTCONST 33 (0x21)
> I8I4LDID 0 <st 15> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U1ISTORE 0 T<58,anon_ptr.,8> {line: 1/16} {freq: 0, ln: 16, col: 0}
> sym5v29 <- chi( sym5v16 ) NOT LIVE
> sym8v30 <- chi( sym8v19 ) NOT LIVE
> sym9v31 <- chi( sym9v20 ) NOT LIVE
> sym10v32 <- chi( sym10v27 ) NOT LIVE
> I8I4LDID 0 <st 28> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U4U1ILOAD 0 T<6,.predef_U1,1> T<58,anon_ptr.,8>
> mu[ sym5v29 ]
> U4INTCONST 32 (0x20)
> I4U4EQ
> TRUEBR L6146 {line: 1/17} {freq: 0, ln: 17, col: 0}
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> //// deleted dump in between for ease of reading
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> BB11:
> (not live) sym3v37 <- phi(sym3v28,sym3v36)
> (not live) sym10v38 <- phi(sym10v32,sym10v35)
> LABEL L5890 0 {line: 1/17} {freq: 0, ln: 17, col: 0}
> LABEL L770 0 {line: 1/17} {freq: 0, ln: 17, col: 0}
> U4INTCONST 32 (0x20)
> I8I4LDID 0 <st 15> T<4,.predef_I4,4>
> U8LDA 0 <st 5> T<57,anon_ptr.,8>
> U8ADD
> U1ISTORE 0 T<58,anon_ptr.,8> {line: 1/19} {freq: 0, ln: 19, col: 0}
> sym5v39 <- chi( sym5v29 ) NOT LIVE
> sym8v40 <- chi( sym8v30 ) NOT LIVE
> <======== source operand is sym8v30, changed to sym8v19 by DSE
> sym9v41 <- chi( sym9v31 ) NOT LIVE
> sym10v42 <- chi( sym10v38 ) NOT LIVE
> I4I4LDID 0 <st 15> T<4,.predef_I4,4>
> I4INTCONST 1 (0x1)
> I4I4GT
> FALSEBR L7426 {line: 1/20} {freq: 0, ln: 20, col: 0}
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Base on the above analysis, I think the cause of the bug is as follows:
> 1. DSE thinks sym8v30 <- chi( sym8v19 ) is not live, hence, changed
> all subsequent references of sym8v30 to sym8v19
> 2. In Create_CODEMAP, sym8v30 <- chi( sym8v19 ) is resurrected due to
> Iload_folded function in processing mu[ sym5v29 ] node. However,
> references to sym8v19 are not corrected. This caused the assertion
> failure in Verify_version_CR.
>
> --Feng Zhou
>
>
>
> On Thu, Feb 3, 2011 at 3:24 PM, Sun Chan <sun.c...@gmail.com> wrote:
> > sorry, can you state your problem clearer? What is before? What is
> > after? In a running example?
> > This problem is quite fundamental. Code in DSE and iload folding has
> > not been touched for a very long time. I'd like to understand your
> > problem better first.
> > Sun
> >
> > On Fri, Feb 4, 2011 at 6:11 AM, Feng Zhou <fengzho...@gmail.com> wrote:
> >> Hello,
> >>
> >> Can gatekeeper review the attached fix for bug
> >> #707(https://bugs.open64.net/show_bug.cgi?id=707) please? Thank you.
> >>
> >>
> =========================================================================================
> >> In WOPT, after SSA pointer alias analysis, DSE is performed. So, you
> >> will have code like the following (BB3 dom BB12):
> >>
> >> BB3: ISTORE .. *s1
> >> v_2 <- chi (v_1) NOT LIVE *s2
> >>
> >> BB12: ILOAD ... *s3
> >> v_3 <- chi(v_1) *s4 // was v_3 <- chi(v_2)
> >> before DSE
> >>
> >> Then, in SSA::Create_CODEMAP, while processing the ILOAD WHIRL (*s3)
> >> node, we try to fold it by calling Iload_folded function
> >> which in some cases may resurrect a dead CHI node (*s2). In this case,
> >> (*s2) is resurrected without changing back the
> >> reference of v_1 in (*s4). This causes the live range of v_2 and v_1
> >> to intersect after SSA::Create_CODEMAP and caused
> >> assertion failure in opt_verify. The fix is to undo what DSE did by
> >> changing all the subsequent references of (*s2)'s operand
> >> into its result.
> >>
> ==========================================================================================
> >>
> >>
> >> --Feng Zhou
> >>
> >>
> ------------------------------------------------------------------------------
> >> The modern datacenter depends on network connectivity to access
> resources
> >> and provide services. The best practices for maximizing a physical
> server's
> >> connectivity to a physical network are well understood - see how these
> >> rules translate into the virtual world?
> >> http://p.sf.net/sfu/oracle-sfdevnlfb
> >> _______________________________________________
> >> Open64-devel mailing list
> >> Open64-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>
> >>
> >
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
