[LLVMdev] Scheduler Roadmap

[Andrew Trick]

On May 11, 2012, at 9:53 AM, Sergei Larin <slarin at codeaurora.org> wrote:
>  - We do need to have a way to assign bundles much earlier than we do now.
> And it needs to be intertwined with scheduling (Bundler currently reuses a
> good chunk of scheduler infrastructure). It is also obvious that it will
> have adverse effect on all the downstream passes. It is further insulting
> due to the fact that bundling is trivial to do during scheduling, but it
> goes hard against the original assumptions made elsewhere. Re-bundling is
> also a distinct task that might need to be addressed in this context.

The design was intended to support integrated scheduling and bundling before regalloc. The scheduler only needs to set the instructions' "isInsideBundle" flag. Being an early user, you may run into regalloc bugs. If so, we'll try to get them fixed.

The trickiest part of this is updating LiveIntervals. We should provide a better API for your bundler with, but I don't want to have that discussion until you completely understand what's available today and are ready to test improvements.

>  - We do need to have at least a distant plan for global scheduling. BB
> scope is nice and manageable, but I can easily get several percent of
> "missed" performance by simply implementing a pull-up pass at the very end
> of code generation... meaning multiple opportunities were lost earlier.
> Current way to express and maintain state needed for global scheduling
> remains to be improved.

I sympathize. Global scheduling is fun, and superblock scheduling is not hard. Unfortunately, it is not a problem I'm attacking in the foreseeable future (it's not in the "roadmap"). Finding creative ways to compensate is probably worthwhile. An early code motion pass (before coalescing), linearizing the CFG to appear like one block before scheduling, and potentially splitting when you're done scheduling... Anything beyond this will require you to write your own DAG builder. If you're successful at that, and want to contribute back with enough interest from other developers, then we can talk about merging the infrastructure.

>  - SW pipelining and scheduler interaction with it. When (not if:) we will
> have a robust SW pipeliner it will likely to take place before first
> scheduling pass, and we do not want to "undo" some decision made there.

OK. I think it's a mechanical problem.

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