[PATCH] D17260: SystemZ scheduling implementation

[Andrew Trick via llvm-commits]

atrick added inline comments.

================
Comment at: lib/Target/SystemZ/SystemZISelLowering.cpp:123-138
@@ -118,8 +122,18 @@
 
-  // TODO: It may be better to default to latency-oriented scheduling, however
-  // LLVM's current latency-oriented scheduler can't handle physreg definitions
-  // such as SystemZ has with CC, so set this to the register-pressure
-  // scheduler, because it can.
-  setSchedulingPreference(Sched::RegPressure);
+  // XXJ Experimental.
+  if (Subtarget.isZ10orGeneric())
+    setSchedulingPreference(Sched::RegPressure);
+  else {
+    if (SchedPref=="source")
+      setSchedulingPreference(Sched::Source);
+    else if (SchedPref=="hybrid")
+      setSchedulingPreference(Sched::Hybrid);
+    else if (SchedPref=="ilp")
+      setSchedulingPreference(Sched::ILP);
+    else if (SchedPref=="regpress")
+      setSchedulingPreference(Sched::RegPressure);
+    else
+      llvm_unreachable("bad schedpref string");
+  }
 
   setBooleanContents(ZeroOrOneBooleanContent);
----------------
jonpa wrote:
> atrick wrote:
> > Right, I was looking at your PostRA policy, which is rightly top-down. That said, you might still achieve better register pressure results by a two-pass scheduling approach. I tried hard to wedge all heuristics into a single pass because I was paranoid about compile time.
> > 
> > Ultimately it's whatever works for  your target, I was just pointing out that
> > - SelectionDAG is a bad place for scheduler heuristics
> > - We could support a multiple-pass MI scheduler if anyone needs it
> I am curious as to what you think would be the possibilities of a multi-pass scheduling approach. I have tried this once before like: First do a minimal reg-pressure scheduling. Then increase parallelism (overlapping live intervals) only when it seems to not cause too much spilling. Is this also what you had in mind?
> 
> Currently this is not needed for SystemZ, as the main focus at least right now is on JIT compilation.
> 
Yes that's what I had in mind. I didn't take that approach because I wanted to preserve source order in common cases where an out-of-order target has enough registers, as well as compile time.


http://reviews.llvm.org/D17260