delayed branches and zero overhead loops

[Joern Rennecke <joernr at arc dot com>]

The ARCompact architecture has delay slots and zero overhead loops.
I see that there is already a cgen simulator with delay slots, for the iq2000.
I've looked at its mloop.in xextract-pbb case, and found that
it might decode one more instruction than max_insns, when the pbb ends with
a delay slot insn.
Is that a bug, or legitimate?

For zero overhead loop processing, I think the pbb handling makes most sense
when a pseudo instruction is inserted at the end of a loop, and when the
loop end is changed, any afected pbb is invalidated.

Like for delay slots, this pseudo instruction will need and extra decoded
insn slot, so again it is important to know if it is allowed to use one extra
slot.
A further problem is that I don't want to have a nonsense encoding for
the pseudo insn which could be triggered by invalid code, and/or cause decoder
conflicts.  Hence, there should be a way to define instruction semantics
without an instruction encoding.
What do you think would the bets way to express this?
No format field?  Treating an empty format field in a special way?
Adding a magic attribute that causes the format field (or its absence) to
be ignored?