delay branch bug?

[Hariharan Sandanagobalane]

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
>>