From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Friday, October 07, 2011 11:21 PM
To: Gilmore, Doug
Cc: open64-devel@lists.sourceforge.net
Subject: Re: [Open64-devel] Fix for bug 771, problem in global value numbering.
Looks like the opt_vn.cxx_patch is unnecessary?
[Doug: ] Right, the patch is just to produce debugging output, which is not to
be checked in.
For the other two patches, they are OK to me.
[Doug: ] Thanks! -- Doug
2011/10/8 Gilmore, Doug <doug.gilm...@amd.com<mailto: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<mailto: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
