[PATCH] D43329: [SystemZ, MachineScheduler] Refactor GenericScheduler::tryCandidate() to reuse parts in a new SystemZ scheduling strategy.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 19 08:57:48 PST 2018


fhahn added inline comments.


================
Comment at: include/llvm/CodeGen/MachineScheduler.h:981
+                                   SchedBoundary *Zone);
+  virtual void tryCandidate(SchedCandidate &Cand, SchedCandidate &TryCand,
+                            SchedBoundary *Zone);
----------------
jonpa wrote:
> fhahn wrote:
> > jonpa wrote:
> > > fhahn wrote:
> > > > I think for now it seems like making tryCandidate a virtual function gives peopl eenough freedom to ship their own heuristics while re-using most of the existing bits. I don't see the benefit of making the helper functions class members however.
> > > > 
> > > > Also, tryCandidate should not modify the scheduler state, so I think it should be `const`.
> > > > 
> > > > And as this is part of the interface now and we expect people to extend it, it would be good to document it.
> > > How are those bits going to be reused if not by inheritance?
> > > 
> > > How do you picture SystemZ adding this simple heuristic (see top of page) while reusing all else?
> > > 
> > > How do you picture SystemZ adding this simple heuristic (see top of page) while reusing all else?
> > 
> > They do not have to be member functions, they could be regular exported functions. They don't access the scheduler object (I think), so I don't think they would need to be member functions. To me, it seems simpler not to couple the scheduler and the heuristics too much, but that's again mostly personal perference.
> I tried removing the 'static' from such a function in MachineScheduler.cpp, and then adding an 'extern' declaration in SystemZMachineScheduler.cpp, but that lead to a lot of linker errors. How would you do this?
> 
ah sorry. I meant removing static and moving the declaration to the header file.


https://reviews.llvm.org/D43329





More information about the llvm-commits mailing list