[PATCH] D16353: [mips] MIPSR6 compact branch support

[Vasileios Kalintiris via llvm-commits]

vkalintiris added a comment.

In http://reviews.llvm.org/D16353#332475, @sdardis wrote:

> Apologies, comment didn't get posted, reproduced here:
>
> > Shouldn't we just take care so that the MipsDelaySlotFiller pass does not create any hazards in the first place?
>
>
> For this patch that approach could be taken but I think its better it introduce a fairly specific pass to handle forbidden slot hazards.
>
> Handling hazards as a separate pass introduces a high level of safety as then compact branches can be produced anywhere in the compilation pipeline without the subtly incorrect reliance that the delay slot filler will fix those hazards. It's a separation of concerns issue in my view.
>
> Aside: GCC for MIPS uses a very similar hazard strategy for forbidden slot, hi/lo and delayed value hazards.
>
> Thoughts?


Following this approach means that the MipsDelaySlotFiller pass will no longer generate correct output code, even in the presence of correct input code. As far as I can tell, the code generator provides (or at least it should provide) correct input code to the MipsDelaySlotFiller pass as it does not generate any CTIs in any slot.

Even if we start emitting CTIs in forbidden slots for some unforeseeable reason in the future, conceptually, the MipsDelaySlotFiller pass would be the more appropriate place to remove them as it is responsbile for the handling
of slots either way.

Having said that, I wouldn't be against a dedicated hazard handling pass if we couldn't avoid generating them from the code generator, or handle them at the right pass.


http://reviews.llvm.org/D16353