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
