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
