This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

John David Anglin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]