We also find the IA build fail due to the fix. We already make a patch to fix the problem, will send out review soon.
zhuqing 2011/10/11 shenrfen <shenr...@gmail.com>: > 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 > ------------------------------------------------------------------------------ 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
