Shobaki, Ghassan via llvm-dev
2017-Aug-30 02:38 UTC
[llvm-dev] Mischeduler: Unknown reason for peak register pressure increase
Hello Matthias, Thank you for the clarifications! We are aware of register units and sub-typing, but this is not the issue. We could not find any register from the same group (AH, AL, RAX, etc.) defined in the scheduling region or in the live-in set. We found RAX defined in one of the boundary instructions (not in the region itself), but that instruction defines other registers too. So, we don’t know why RAX (or a sub-register of it) appears in the live-out list, but the other registers defined by that boundary instruction do not. Overall, we need a better understanding of the logic of live-in and live-out when the block is divided into scheduling regions with boundary instructions in between. More specifically, does the live-out set of a region include the registers defined by a boundary instruction that follows the region? Are boundary instructions considered part of the region or not? If yes, do they belong to the region the precedes them or to the one the follows them? The scheduler that we are integrating into the machine scheduling framework needs to know the live-in and live-out registers for the scheduling region as well as the Def and Use sets of each instruction in the region. Our scheduler adds an artificial entry instruction and an artificial exit instruction to each scheduling region. Live-in registers constitute the Def set of the artificial entry instruction and Live-out registers constitute the Use set of the artificial exit instruction. That way, our scheduler tracks and minimizes the register pressure in the region for every register type. Given this need, we would appreciate any clarifications or pointers to specific data structures. You have also mentioned that register pressure estimates are not absolute. This is an interesting issue that we will address in a separate email. Thanks Ghassan Shobaki Assistant Professor of Computer Science California State University, Sacramento -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170830/24b6ffbd/attachment.html>