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

Matthias Braun via llvm-dev
Fri, 13 Oct 2017 22:49:31 -0000

> 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>