this is the kind of trace I had always wanted from day one. Thx for taking the trouble to doing that right. Sun
On 10/7/11, Jian-Xin Lai <laij...@gmail.com> wrote: > Looks like the opt_vn.cxx_patch is unnecessary? > For the other two patches, they are OK to me. > > 2011/10/8 Gilmore, Doug <doug.gilm...@amd.com> > >> 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 of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2dcopy2 >> _______________________________________________ >> Open64-devel mailing list >> Open64-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/open64-devel >> >> > > > -- > Regards, > Lai Jian-Xin > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
