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

[Simon Dardis via llvm-commits]

sdardis added a comment.

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?


================
Comment at: lib/Target/Mips/Mips.h:34
@@ -33,2 +33,3 @@
   FunctionPass *createMipsConstantIslandPass(MipsTargetMachine &tm);
+  FunctionPass *createMipsHazardSchedule(MipsTargetMachine &tm);
 } // end namespace llvm;
----------------
vkalintiris wrote:
> Do we really need this pass? Shouldn't we just take care so that the MipsDelaySlotFiller pass does not create any hazards in the first place?
> 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?


http://reviews.llvm.org/D16353