Hi Jian-Xin,
This is a good fix. Please check it in. Thanks.
Fred
On 03/05/2011 08:37 PM, Jian-Xin Lai wrote:
Hi,
Could a gate keeper review the patch to bug 740? Thank you very much.
This bug occurs in COMP_UNIT::Lower_to_extract_compose().
Before this phase, the IR in BB6 is:
(not live)(dse-dead) sym2v26 <- phi(sym2v20,sym2v44)
sym7v4<cr24> <- phi(sym7v0<cr14>,sym7v0<cr14>)
sym9v4<cr26> <- phi(sym9v3<cr22>,sym9v8<cr38>)
> LDID U4 U4 sym3v2 51 ty=3b02 <u=2 cr5> flags:0x10 b=-1
> I4I1ILOAD 0 ty=3522 <u=0 cr27> flags:0x0 b=-1 mu<9/cr26>
>OPR_STID I4 I1 sym2v5 0 <u=1 cr28> b=-1 flags:0x12 pj2 Sid-1
chi <7/cr14/cr24 9/cr29/cr26 > 0x0x810f658
After this phase, the IR in BB6 is:
(not live)(dse-dead) sym2v26 <- phi(sym2v20,sym2v44)
sym7v4<cr24> <- phi(sym7v65535<cr48>,sym7v65535<cr63>)
sym9v4<cr26> <- phi(sym9v3<cr22>,sym9v8<cr38>)
> LDID I4 I4 sym7v4 0 ty=3a02 <u=0 cr24> flags:0xa b=-1 #id
> LDID U4 U4 sym3v2 51 ty=3b02 <u=2 cr5> flags:0x10 b=-1
> I4I1ILOAD 0 ty=3522 <u=0 cr27> flags:0x0 b=-1 mu<9/cr26>
> I4COMPOSE_BITS o:0 s:8 <u=1 cr64> isop_flags:0x0 flags:0x0 b=-1
>OPR_STID I4 I4 sym7v65535 0 <u=0 cr51> b=-1 flags:0x2 pj2 Sid-1
chi <9/cr29/cr26 2/cr28/cr4 > 0x0x810f658
sym2 is id.info <http://id.info>(ofst=0, size=8bit), sym7 is id
(ofst=0, size=32bit). sym9 is default vsym.
There is an entry chi for sym2 in BB1:
>OPR_OPT_CHI b=-1 flags:0x2 pj2 Sid-1
chi <1/cr1/cr2 2/cr3/cr4, ...>
When we verify the version of sym2, after entry CHI, the live version
of sym2 should b2 sym2v3. But sym2v4, which is the zero version, is
used in the chi of the STID. So the assertion is triggered.
The problem exists in
OPT_REVISE_SSA::Find_scalars_from_lowering_bitfld_cr(). When it tries
to promote the STID on first 6bit of id to 32bit, it only add the sym7
into the "_symbols_to_revise" list. sym2 is not added:
else if (cr->Dtyp() != MTYPE_M && MTYPE_byte_size(cr->Dsctyp()) < 4 &&
(idx = _opt_stab->Part_of_reg_size_symbol(cr->Aux_id()))
!= 0) {
cr->Set_promote_to_reg_size(); // flag this cr for processing in
step 2
_symbols_to_revise->Union1D(idx);
cr->Set_scalar_aux_id(idx);
_has_bitfield = TRUE;
In the following renaming phase, the phi of sym2 on BB6 is still
dse-dead. So the zero-ver of sym2 is pushed to the stack then used as
the OPND of the chi on the STID. But the sym2v3 defined by entry CHI
are still alive at that point.
My fix is to add the sym2 into the "_symbols_to_revise" list. So that
the phi of sym2 can be revised and the version is renamed correctly.
Index: ../osprey/be/opt/opt_revise_ssa.cxx
===================================================================
--- ../osprey/be/opt/opt_revise_ssa.cxx (revision 3506)
+++ ../osprey/be/opt/opt_revise_ssa.cxx (working copy)
@@ -280,6 +280,7 @@
else if (cr->Dtyp() != MTYPE_M && MTYPE_byte_size(cr->Dsctyp()) <
4 &&
(idx = _opt_stab->Part_of_reg_size_symbol(cr->Aux_id()))
!= 0) {
cr->Set_promote_to_reg_size(); // flag this cr for processing
in step 2
+ _symbols_to_revise->Union1D(cr->Aux_id());
_symbols_to_revise->Union1D(idx);
cr->Set_scalar_aux_id(idx);
_has_bitfield = TRUE;
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
