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.ang...@bell.net
