Re: Pipeline hazards and delay slots

[Boris Boesler <baembel at gmx dot de>]

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.


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

Boris