llvm dev - Nov 2017 - mischeduler (pre-RA) experiments

>
> 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
> copy-paste.

​Isn't GCNMaxOccupancySchedStrategy [1] already an example on
using GenericScheduler as the base class?

[1] http://llvm.org/doxygen/classllvm_1_1GCNMaxOccupancySchedStrategy.html


-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171125/7633b9a0/attachment.html>

> On Nov 24, 2017, at 6:00 PM, 陳韋任 <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
> copy-paste.
> 
> ​Isn't GCNMaxOccupancySchedStrategy [1] already an example on using
GenericScheduler as the base class?
> 
> [1] http://llvm.org/doxygen/classllvm_1_1GCNMaxOccupancySchedStrategy.html
<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”.
-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171125/da8c56c8/attachment.html>

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
>>     copy-paste.
>>
>>
>> ​Isn't GCNMaxOccupancySchedStrategy [1] already an example on 
>> using GenericScheduler as the base class?
>>
>> [1]
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”.
> -Andy
>

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.

Cheers,
Florian