radeon/llvm: Use the VLIW Scheduler for R600->NI

It's not optimal, but it's better than the register pressure scheduler
that was previously being used.  The VLIW scheduler currently ignores
all the complicated instruction groups restrictions and just tries to
fill the instruction groups with as many instructions as possible.
Though, it does know enough not to put two trans only instructions in
the same group.

We are able to ignore the instruction group restrictions in the LLVM
backend, because the finalizer in r600_asm.c will fix any illegal
instruction groups the backend generates.

Enabling the VLIW scheduler improved the run time for a sha1 compute
shader by about 50%.  I'm not sure what the impact will be for graphics
shaders.  I tested Lightsmark with the VLIW scheduler enabled and the
framerate was about the same, but it might help apps that use really
big shaders.

1 files changed, 11 insertions, 0 deletions

diff --git a/src/gallium/drivers/radeon/R600InstrInfo.cpp b/src/gallium/drivers/radeon/R600InstrInfo.cpp
index d1246d3e0ff..e11c0bd60f7 100644
--- a/src/gallium/drivers/radeon/R600InstrInfo.cpp
+++ b/src/gallium/drivers/radeon/R600InstrInfo.cpp
@@ -13,8 +13,12 @@
 
 #include "R600InstrInfo.h"
 #include "AMDGPUTargetMachine.h"
+#include "AMDILSubtarget.h"
 #include "R600RegisterInfo.h"
 
+#define GET_INSTRINFO_CTOR
+#include "AMDGPUGenDFAPacketizer.inc"
+
 using namespace llvm;
 
 R600InstrInfo::R600InstrInfo(AMDGPUTargetMachine &tm)
@@ -92,3 +96,10 @@ bool R600InstrInfo::isMov(unsigned Opcode) const
     return true;
   }
 }
+
+DFAPacketizer *R600InstrInfo::CreateTargetScheduleState(const TargetMachine *TM,
+    const ScheduleDAG *DAG) const
+{
+  const InstrItineraryData *II = TM->getInstrItineraryData();
+  return TM->getSubtarget<AMDILSubtarget>().createDFAPacketizer(II);
+}