This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: delay branch bug?
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Hariharan <hariharans at picochip dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 24 May 2010 16:30:09 +0200
- Subject: Re: delay branch bug?
- References: <4BFA671B.8010800@picochip.com>
> 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.
You'd need to define what "good" means here. The generated code looks correct
since (1) 'a' is on the stack and thus loading from it cannot trap (2) it is
not marked volatile and (3) the result of the load is unused when the memory
location is uninitialized. So, from an external viewpoint, the generated
code behaves as if there were no "problematic" loads and looks therefore OK.
--
Eric Botcazou