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
bug771.patch
Description: bug771.patch
trace_cleanup.patch
Description: trace_cleanup.patch
opt_vn.cxx_patch
Description: opt_vn.cxx_patch
------------------------------------------------------------------------------ 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
