[llvm-dev] MachineScheduler not scheduling for latency

[Andrew Trick via llvm-dev]

> On Sep 25, 2019, at 2:09 AM, Jay Foad <jay.foad at gmail.com> wrote:
> 
> One of the effects I'm seeing is that small changes in the input cause
> drastic changes in the resulting schedule. This makes life difficult
> because innocuous changes elsewhere in the compiler can apparently
> cause large performance regressions which we have to track down.

Yes. This sort of thing also happens a lot because of unpredictable register coalescing decisions and even spilling. It’s definitely a major problem for performance tracking.

> And one reason for this is that getOtherResourceCount /
> checkResourceLimit decide whether the code is issue limited or not
> based on the number of ops vs the length of the critical path, which
> can easily flip-flop; and this overrides the result of
> shouldReduceLatency, which affects whether tryCandidate calls
> tryLatency, or falls back to source order.
> 
> Given that #5 is a last resort criterion before falling back to source
> order, I don't understand why it ever makes sense to disable it.

The other, higher priority heuristics should handle situations where latency may cause a stall. This is an aggressive heuristic that overall tries to bias scheduling in one direction to the likely detriment of register pressure. Enabling an aggressive heuristic unconditionally introduces regressions where it would have been better to do no scheduling at all. That would actually make the scheduler a bigger source of performance noise.

Of course, every target and set of important workloads is different, which is why it’s easy to plugin your own heuristics. Or, if this change is useful for other targets as well, we could consider adding a property to the machine model that tells the generic scheduler to be unconditionally latency aggressive. Before considering that, it’s important to be sure which heuristics are really in play and verify that it would improve your performance noise problem across a wide range of programs.

As an aside, if I had continued working on instruction scheduling, I would have worked on classifying code patterns before scheduling and using that classification to determine a strategy.

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