[llvm-dev] mischeduler (pre-RA) experiments
Andrew Trick via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 27 08:40:23 PST 2017
> On Nov 27, 2017, at 8:12 AM, Florian Hahn <florian.hahn at arm.com> wrote:
> On 25/11/2017 18:10, Andrew Trick via llvm-dev wrote:
>>> On Nov 24, 2017, at 6:00 PM, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw <mailto:chenwj.cs97g at g2.nctu.edu.tw>> wrote:
>>> Of course, you want to duplicate as little of the generic
>>> scheduling logic as you can. So I think the challenge is how to
>>> expose the
>>> generic scheduler's functionality as a base class or composition
>>> of utilities so that defining your strategy doesn't require too much
>>> Isn't GCNMaxOccupancySchedStrategy  already an example on using GenericScheduler as the base class?
>>>  http://llvm.org/doxygen/classllvm_1_1GCNMaxOccupancySchedStrategy.html
>> Yes. I think GenericScheduler and related logic should continue to evolve to make that approach easier and more clear. The idea should be “take what you need and build on top". Not “take everything and randomly fiddle with dozens of knobs”.
> Yes, at the moment, re-using functionality from GenericScheduler is quite hard.
> A quite simple (and naive) way to make the existing infrastructure more re-usable would be to make GenericScheduler::tryCandidate virtual or allow providing a scheduler that takes a tryCandidate function as argument. To tune the heuristics, all people would have to do is to provide their target-specific tryCandidate function and re-use the logic to do bottom-up/top-down scheduling + the processor simulation in SchedBoundary. I think this could cover most use-cases, where people just want to tweak the heuristics.
> If dynamic dispatch is a concern compile-time wise, I am sure we could come up with a templated version or something else to get the same thing with static dispatch.
> What do you think? I would be quite happy to prototype something along those lines, as I think this would be helpful when migrating other backends to the MachineScheduler, e.g. for the ARM backend, slight tweaks to the heuristics seems beneficial. Having them in a target specific scheduler would make things easier.
I think there’s enough work being done in tryCandidate that dynamic dispatch is not a concern.
More information about the llvm-dev