delay branch bug?

[Jeff Law]

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

Jeff
>
> Thanks
> Hari
>