Support defining how instructions consume delay slots

[Alkalem]

What is the feature you'd like to have?
The architecture API supports defining variable delay slots for branch instructions. After a branch instruction with branch delay, each decoded instruction consumes one delay slot. It would be great if an architecture plugin could define the number of delay slots an instruction consumes.

Is your feature request related to a problem?
For instruction with branch delay and instruction level parallelism, defining the branch delay without knowledge about future instructions fails. Instructions that are executed in parallel only might be encoded separately, but consume only a single delay slot. Similarly, a single instruction might consume multiple delay slots. Correct

Are any alternative solutions acceptable?
It should be possible to work around the missing feature. An architecture plugin either needs to look ahead or keep state for delayed branches. Adapting from suggestions mentioned in #866, one could lie about the maximum instruction size, increase it such that all instruction that might execute in a delay slot are included and calculate the actual branch delay for branch instructions. While this or similar solutions might work, the requested feature would make it much simpler and cleaner IMO.

Additional Information:
I am currently working on an architecture plugin for a TI DSP. It has a branch delay of 5. Up to 8 instructions can be executed in parallel. Each instruction encodes if it is executed in parallel with the next instruction. Additionally, there is a NOP instruction that can take multiple cycles to wait for instructions like branches to complete.

This feature would be useful for any architecture with branch delay and ILP.

Currently, the InstructionInfo.delaySlots field seems to be used only for branch instructions. This field could be used to define how instructions consume delay slots. Then 0 could be used for parallel execution of instructions or n>1 for instructions like my NOP.

[zznop]

This is a duplicate of #551 and #742

We are currently finalizing changes to the architecture sub-system to allow for what we're calling "function level lifting". Once finished, the architecture class will contain a AnalyzeBasicBlocks method that can be overridden by architecture plugins to perform custom basic block analysis on the entire function at once. This method takes a Function object and analysis settings as input, and populates the function's basic blocks.

Currently, AnalyzeBasicBlocks lives in core and it invokes the GetInstructionInfo callback on each instruction to build the control flow graph. It handles the branch delay slots for PPC and other architectures, internally. Once AnalyzeBasicBlocks is exposed to the API, you'll be able to handle delay slots however you want. Not only will this feature allow for support of handling parallel pipelines, but it will also allow for Binja to model hardware loops and other complex control flow that we don't currently have a great answer for.

As for lifting for TI DSP, I recommend lifting entire pipelines of instructions at once. You mentioned that in TI DSP up to 8 instructions can be executed in parallel. The default instruction length should be set to the maximum amount of bytes needed for 8 instructions (you'll return the number of bytes consumed if the instruction packet is smaller). All instructions in the pipeline should be lifted in a single invocation of GetInstructionLowLevelIL. This can all be done today to support parallel pipelines, and is how we currently handle delay slots.