This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: delay branch bug?




Jeff Law wrote:
On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had the following bit of code (Note that "get" builtin functions in picochip stand for port communication)


int mytest ()
{
 int a[5];
 int i;
 for (i = 0; i < 5; i++)
 {
   a[i] = (int) getctrlIn();
 }
 switch (a[3])
 {
   case 0:
       return 4;
   default:
       return 13;
 }
}

The relevant bit of assembly for this compiled at -Os is

_L2:
       GET 0,R[5:4]    // R[5:4] := PORT(0)
_picoMark_LBE5=
_picoMark_LBE4=
       .loc 1 13 0
       STW R4,(R3)0            // Mem((R3)0{byte}) := R4
       ADD.0 R3,2,R3   // R3 := R3 + 2 (HI)
       .loc 1 11 0
       SUB.0 R3,R2,r15 // CC := (R3!=R2)
       BNE _L2
       =->     LDW (FP)3,R5            // R5 = Mem((FP)6{byte})
       .loc 1 22 0

=-> is the delay slot marker. Note that the LDW instruction has been moved into the delay slot. This corresponds to the load in "switch (a[3]" statement above. The first 3 times around this loop, LDW would be loading uninitialised memory. The loaded value is ignored until we come out of the loop and hence the code is functionally correct, but i am not sure introduction of uninitialised memory access by the compiler when there was none in the source is good.

I browsed around the delay branch code in reorg.c, but couldn't find anything that checks for this. Is this the intended behaviour? Can anyone familiar with delay branch code help?
It's not ideal, but there's no way for reorg to know that a particular memory location is uninitialized as a result trying to "fix" this problem would ultimately result in reorg not being allowed to fill delay slots with memory references except under very very restrictive circumstances.

From a correctness standpoint, the uninitialized value will never be used, so it should cause no ill effects on your code. The biggest effect would be tools like valgrind & purify (if supported on your architecture) would report the uninitialized memory read. [Which begs the question how does purify handle this on sparc-solaris? ]
The code compiled for picochip runs under a simulator. The simulator tracks uninitialised memory accesses and emits warnings and hence my question. I would agree with you that turning off delay slot filling of memory references for this sake doesn't make sense.

Thanks for your help.

Cheers
Hari


Jeff

Thanks Hari



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]