[llvm-dev] Machine Scheduler on Power PC: Latency Limit and Register Pressure

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 13 15:49:31 PDT 2017


> On Oct 13, 2017, at 3:01 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
>> On Oct 13, 2017, at 1:46 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote:
>> 
>> Yes, I've run into the problem myself that the Pending queue isn't even checked with the tryCandidate() logic and so takes priority over all other scheduling decisions.
>> 
>> I personally would be open to changes in this area. To start the brainstorming I could imagine that we move nodes below a target specific limit into the available queue instead of just when they hit their latency cycle limits. And then let tryCandidate() weight the remaining cycles against other scheduling criteria.
>> 
>> Also keep in mind:
>> - When making those changes be careful getting cycle bumping/simulation logic right
>> - The pending queue is also used as a mechanism to keep compile time (see ReadyListLimit) in check (as checking every candidate for every instruction we schedule is O(n**2)).
>> 
>> - Matthias
> 
> No, it doesn’t make any sense to schedule something from the pending queue if there are still instructions that can be scheduled in the current cycle. Those available instructions can effectively be scheduled “for free”. Scheduling them first won’t delay anything in the pending queue!
> 
> If that’s not the case then there’s something wrong with your model. Or if this kind of VLIW-style scheduling isn’t what you wanted, then you shouldn’t have ordered it:
Though if you happen to increase register pressure resulting in extra spills and reloads then these instructions aren't really free anymore (as you will get extra cycles later when the spill/reloads are inserted).

This may or may not be a good thing to schedule for, would be interesting to at least experiment a bit and see if it would improve things.

- Matthias

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


More information about the llvm-dev mailing list