<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 13, 2017, at 3:01 PM, Andrew Trick via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Oct 13, 2017, at 1:46 PM, Matthias Braun <<a href="mailto:matze@braunis.de" class="">matze@braunis.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Also keep in mind:</div><div class="">- When making those changes be careful getting cycle bumping/simulation logic right</div><div class="">- 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)).</div><div class=""><br class=""></div><div class="">- Matthias</div></div></div></blockquote><div class=""><br class=""></div><div class="">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!</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">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:</div></div></div></blockquote><div><div>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).</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>- Matthias</div><blockquote type="cite" class=""><div class=""></div></blockquote></div></div><br class=""></body></html>