Hi all, Could a gatekeeper review the attached patch for bug #824?
symptoms
--------
int one;
float i[5];
main()
{
i[4] = 1.0;
one = *((int *)&i[4]);
printf("%d\n", one);
printf("%f\n", i[4]);
}
If the above test case is compiled with "-fpic", an assembly
instruction that loads into the address register (%rcx in this case)
gets deleted, and the resulting code fails with Segmentation fault.
$ opencc try1.c -fpic -S
$ opencc try1.s
$ ./a.out
Segmentation fault
analysis
--------
The offending instruction is the following instruction that tries to
access memory in %rcx.
movss %xmm0,16(%rcx) # [0] id:9 i+0x10
However, %rcx is not defined anywhere in the code and its value is
zero during run time.
Investigating the compiler's internal processing, it is TN151 that
keeps the address value. The following is the correct CG IR before the
first EBO call.
[ 5, 0] TN151 :- ld64 GTN34(%rip) (sym:i+0) ; noalias WN id:9 i+0x10
[ 5, 0] :- stss TN149 TN151 (0x10) ; WN id:9 i+0x10
After the first call to EBO, however, the upper OP gets deleted, which is wrong.
The OP was deleted from 'EBO_Remove_Unused_Ops' but TN151's reference
count was zero when it was deleted. The source of this wrong reference
count is that 'Special_Store_Load_Sequence' decreased the reference
count without deleting the OP itself. For the attached test case, EBO
tried to replace
TN149 :- ldss TN150 (0x0) // mem1
:- stss TN149 TN151 (0x10) // mem2
TN152 :- ld32 TN151 (0x10) // mem2
with
TN149 :- ldss TN150 (0x0) // mem1
:- stss TN149 TN151 (0x10) // mem2
TN152 :- ld32 TN150 (0x0) // mem1
EBO only adds the new OP4 with the mem1 while not deleting the load
from mem2. The code is as follows:
OP1: TN149 :- ldss TN150 (0x0) // mem1
OP2: :- stss TN149 TN151 (0x10) // mem2
OP3: TN152 :- ld32 TN151 (0x10) // mem2
OP4: TN152 :- ld32 TN150 (0x0) // mem1
But EBO incorrectly decreases the reference count of TN151. When the
OP3 got deleted later, the reference count of TN151 is decreased
again, which causes the reference count of TN151 to be zero, and the
definition of TN151 got deleted.
fix
---
My fix is to remove the code that decreases reference count in
'Special_Store_Load_Sequence'. The same function is also in Loongson
but it's an empty function that always returns false, and it needs not
be fixed there.
Thanks
zhuqing
824.patch
Description: Binary data
------------------------------------------------------------------------------ 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-d2dcopy1
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
