Re: Pipeline hazards and delay slots

["Mohamed Shafi" <shafitvm at gmail dot com>]

On Mon, May 5, 2008 at 1:12 PM, Boris Boesler <baembel@gmx.de> wrote:
> Hi!
>
>  Am 05.05.2008 um 09:06 schrieb Mohamed Shafi:
>
>
>
> >
> > >
> > > > But how can i handle instances like this? Should i be doing insertion
> > > > of nops in reorg pass?
> > > >
> > >
> > > FWIW, I had worked on a port for VLIW processor about three years back
> > > and IIRC we had used the reorg pass for inserting the nops.  I think
> > > if you look at the scheduler dumps  you will notice that the scheduler
> > > would have, in all likelihood, accounted for the delay of 1 cycle
> > > between the "lw" and the "add" instructions. Only that you will have
> > > to put the "nop" yourself between these two instructions.
> > >
> > >
> >  Thanks for your reply.
> >  Thats what i am doing right now. But i am not doing in reorg pass
> > but in final_prescan.
> >
>
>   I don't know about final_prescan but the insn code seems to get modified
> somewhere (more than once?) after the machine dependent reorg pass. Ian
> suggested to reorg the code in TARGET_ASM_FUNCTION_PROLOGUE. That's what I
> am doing. But that has some other disadvantages.
>

   In final_prescan one actually emits nop instruction in the assembly
file. The disadvantage of this length calculation for indirect jump
goes wrong as compiler will not have any idea emitted nops. So i moved
nop generation to reorg pass.

>
>
>
> > But things go wrong when the two instructions
> > actually are placed in the delay slots. So after filling the delay
> > slot the instructions are like this
> >
>  ...
>
>
> >  This means 3 instruction in delay slots which can have only 2. So my
> > question was how do i overcome this?
> >
>
>   I have similar situations. I simply do not emit these kind of instruction
> in the delay slot!

What i am trying to do now is to examin the delay slots and reschedule
the instructions if required. And thankfully i have gcc back-end 'mt'
also does something similar to this. Hopefully this should slove the
problems.

> You will have another problem: the lw instruction could
> be the last instruction in the delay slot or at the end of a basic block.
> Then you have to schedule across basic block (jump/fall through) and
> function boundaries (call). The first one can be solved by checking code in
> basic block predecessors given by the edges data structure. The second one
> could be ignored if you know the function prologue and can assure that the
> register is not used in the first instruction.

Thanks for the info. Yes i thing i will have to take care of this also.

Thanks for your time.

Regards,
Shafi