Hi, Doug There is no definition of "TCON_R10" for other target! Build fail for other target!
-----Original Message----- From: Gilmore, Doug [mailto:doug.gilm...@amd.com] Sent: Saturday, October 08, 2011 9:07 AM To: open64-devel@lists.sourceforge.net Subject: [Open64-devel] Fix for bug 771, problem in global value numbering. There are two changes I would like to have reviewed. One is trace_cleanup.patch, which cleans up CODEREP tracing output in WOPT. Without the patch the following tracing output is generated: > LDRC F10 0x0x80b67e8 <u=1 cr10> flags:0x0 b=-1 > LDRC F10 0x0x80b68d8 <u=1 cr20> flags:0x0 b=-1 F10DIV <u=1 cr21> > isop_flags:0x0 flags:0x0 b=-1 With it, we have: > LDRC F10 <1,52> <u=1 cr10> flags:0x0 b=-1 > LDRC F10 <1,57> <u=1 cr20> flags:0x0 b=-1 F10DIV <u=1 cr21> > isop_flags:0x0 flags:0x0 b=-1 The other patch to be reviewed the fix to bug 771. The issue is that there are two expressions: > LDRC F10 <1,52> <u=1 cr10> flags:0x0 b=-1 LDRC F10 <1,51> <u=2 cr7> > flags:0x0 b=-1 F10DIV <u=2 cr11> isop_flags:0xcc040 flags:0x1 b=E1 > LDRC F10 <1,52> <u=1 cr10> flags:0x0 b=-1 > LDRC F10 <1,57> <u=1 cr20> flags:0x0 b=-1 F10DIV <u=1 cr21> > isop_flags:0xcc040 flags:0x1 b=E2 Where the symbol table entries are: [51]: <constant> <1,51> Constant of type .predef_F10 (#12, F10) value: 0.0000000000000000000 Address: 0(.rodata<1,58>) Alignment: 16 bytes Flags: 0x00000008 initialized, XLOCAL Sclass: FSTATIC [52]: <constant> <1,52> Constant of type .predef_F10 (#12, F10) value: 1.0000000000000000000 Address: 16(.rodata<1,58>) Alignment: 16 bytes Flags: 0x00000008 initialized, XLOCAL Sclass: FSTATIC ... [57]: <constant> <1,57> Constant of type .predef_F10 (#12, F10) value: -0.0000000000000000000 Address: 0(<1,57>) Alignment: 16 bytes Flags: 0x00000008 initialized, XLOCAL Sclass: FSTATIC The two expressions are incorrectly given the same value number. If we apply the debugging patch opt_vn.cxx_patch, without the patch for the fix we get: $ opencc bug771.c <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 11> = vn39 = OPC_F10DIV(vn37, vn38) <cr 15> = vn41 = LDA cr_id(15) <cr 16> = vn41 = LDA cr_id(15) <cr 14> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 17> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 20> = vn38 = F10_const(0.0000000000000000000) <==== BAD same value number as cr 7 <cr 21> = vn39 = OPC_F10DIV(vn37, vn38) <==== BAD same value number as cr 11 <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 22> = vn42 = OPC_I4F10LT(vn38, vn39) <cr 23> = vn1 = I8_const(0) <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 11> = vn39 = OPC_F10DIV(vn37, vn38) <cr 15> = vn41 = LDA cr_id(15) <cr 16> = vn41 = LDA cr_id(15) <cr 14> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 17> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 20> = vn38 = F10_const(0.0000000000000000000) <cr 21> = vn39 = OPC_F10DIV(vn37, vn38) <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 22> = vn42 = OPC_I4F10LT(vn38, vn39) <cr 23> = vn1 = I8_const(0) With the bad value number, an incorrect CSE transformation is generated. With the fix we see: $ opencc bug771.c <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 11> = vn39 = OPC_F10DIV(vn37, vn38) <cr 15> = vn41 = LDA cr_id(15) <cr 16> = vn41 = LDA cr_id(15) <cr 14> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 17> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 20> = vn42 = F10_const(-0.0000000000000000000) <=== GOOD, not the same as cr 7 <cr 21> = vn43 = OPC_F10DIV(vn37, vn42) <=== GOOD, not the same as cr 11 <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 22> = vn44 = OPC_I4F10LT(vn38, vn43) <cr 23> = vn1 = I8_const(0) <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 11> = vn39 = OPC_F10DIV(vn37, vn38) <cr 15> = vn41 = LDA cr_id(15) <cr 16> = vn41 = LDA cr_id(15) <cr 14> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 17> = vn36 = ==> ...Chi result, or has Bottom opnd <cr 10> = vn37 = F10_const(1.0000000000000000000) <cr 20> = vn42 = F10_const(-0.0000000000000000000) <cr 21> = vn43 = OPC_F10DIV(vn37, vn42) <cr 7> = vn38 = F10_const(0.0000000000000000000) <cr 22> = vn44 = OPC_I4F10LT(vn38, vn43) <cr 23> = vn1 = I8_const(0) $ In this case the bad CSE transformation won't be generated. Note that this problem is handled correctly when the test uses double (F8), so it was just a matter of adding logic to handle long double (F10). BTW, this test program used to work due to broken code in Targ_Is_Integral() for MTYPE_FQ. At that time integral value detection for for MTYPE_FQ was broken, thus HASH_TCON() was used to produce the hash index, causing different the hash indices to be generated for 0.0 and -0.0 of type MTYPE_FQ. The bug in Targ_Is_Integral() was fixed when MTYPE_F10 was introduced. However fixing that exposed this problem. Could someone review these changes when they have the chance? Thanks, Doug ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
