Re: [PATCH] Fix PR middle-end/61141

[John David Anglin <dave dot anglin at bell dot net>]

On 20-May-14, at 5:23 PM, Jeff Law wrote:

> > I believe that the backend must handle the deleted insns in the delay
> > slot as there are are no compilation errors or regressions.
> > However, like you, I'm not 100% certain this done correctly.
> I'm pretty sure we're getting this wrong in the backend.   In fact,  
> the more I think about it, a NOTE_INSN_DELETED in a delay slot is  
> just asking for all kinds of trouble.
>
> In general, if we have an insn with a filled delay slot, then we  
> will emit the two insns independently of each other (most of the  
> time, there are exceptions).
>
> A NOTE_INSN_DELETED in a delay slot still looks like a filled slot.   
> So the target code isn't going to emit a NOP or anything like that.   
> It's going to leave it up to the generic code to emit the insn with  
> the delay slot and the delay slot insn itself (the NOTE_INSN_DELETED  
> in this case).
>
> Of course we don't output anything for a NOTE_INSN_DELETED.  So the  
> net result is we, in essence, fill the delay slot with whatever  
> random instruction happens to fall next in the insn chain.
>
> Amazingly, nothing seems to be failing, but I've seen far worse bugs  
> go unnoticed for a long time.
>
> Sadly,I think we need to start digging deeper to find out what's  
> deleting those insns and take corrective action.
>
> Perhaps writing a little routine to peek at all the filled delay  
> slots and squawk if it finds a NOTE_INSN_DELETED.  Then call it  
> after each RTL pass that follows reorg in the pass manager.  That'd  
> at least narrow it down to a pass that's mucking things up.

The insns are being deleted in "final" after the assembly output has  
being done.  So, for example, pa_output_call is
never called with a delayed branch sequence containing a  
NOTE_INSN_DELETED.

It would seem to me that this "cleanup" should be done before the  
"dbr" pass.

If dbr_sequence() ignored notes, we would emit the nop.  However, it  
doesn't look like it does.  It fairly
easy to check for this case but I hesitate to add code to handle cases  
that aren't supposed to happen.

Dave
--
John David Anglin	dave.anglin@bell.net