<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=""><div><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 6:48 PM, Matthias Braun <<a href="mailto:matze@braunis.de" class="">matze@braunis.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The more I think about it, the more I feel uneasy about the disconnect between the effecitve register reserving via allocation orders and the registers actually reported as reserved. Did you check for example whether the commit below works correctl with the RegisterScavenger?</div></div></div></blockquote><div><br class=""></div><div>No I haven’t, and I am actually pretty sure it does not use the allocation order as you suspect :).</div><div>This is not a correctness problem and if we need the scavenger I guess we are already in a bad situation performance wise. Anyhow, I’d say this is orthogonal, we can improve the scavenger later, but I believe having a clear semantic is best.</div><div><br class=""></div><div>Cheers,</div><div>-Quentin</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> I am pretty sure scavengeRegister() will pick any free register it finds and diregard the allocation order.</div><div class=""><br class=""></div><div class="">- Matthias</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 6:40 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I prefer the hard rule to be fair, i.e., the semantic would be easier to understand.<div class=""><br class=""></div><div class="">Q.<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 6:33 PM, Matthias Braun <<a href="mailto:matze@braunis.de" class="">matze@braunis.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">That would work.</div><div class=""><br class=""></div><div class="">Alternatively we could drop the super-reg being reserved as a hard rule and only recommend it. We could provide the verifier in a function that targets can optionally call, mips just wouldn’t do that then.</div><div class=""><br class=""></div><div class="">- Matthias</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 6:25 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">ARM has a similar problem and we solved it with “fancy” allocation order:<div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">commit 8927f6cd0f8d7614e8682a2da08f0a9769be9603</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Author: Tim Northover <<a href="mailto:tnorthover@apple.com" class="">tnorthover@apple.com</a>></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Date: Mon Aug 3 17:20:10 2015 +0000</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255); min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> ARM: prefer allocating VFP regs at stride 4 on Darwin.</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255); min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><br class="webkit-block-placeholder"></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> This is necessary for WatchOS support, where the compact unwind format assumes</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> this kind of layout. For now we only want this on Swift-like CPUs though, where</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> it's been the Xcode behaviour for ages. Also, since it can expand the prologue</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> we don't want it at -Oz.</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255); min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><br class="webkit-block-placeholder"></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> git-svn-id: <a href="https://llvm.org/svn/llvm-project/llvm/trunk@243884" class="">https://llvm.org/svn/llvm-project/llvm/trunk@243884</a> 91177308-0d34-0410-b5e6-96231b3b80d8</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><blockquote type="cite" class=""><div class="">On Nov 14, 2016, at 6:15 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="">MatzeB added a reviewer: sdardis.<br class="">MatzeB added a comment.<br class=""><br class="">These new rules break existing use in Mips :-(<br class=""><br class="">Mips has 32bit floatregs F0-F31, each pair forms a double reg (<a href="f0+https://reviews.llvm.org/F1=D0" class="">F0+https://reviews.llvm.org/F1=D0</a>, <a href="https://reviews.llvm.org/F2+https://reviews.llvm.org/F3=https://reviews.llvm.org/D1" class="">https://reviews.llvm.org/F2+https://reviews.llvm.org/F3=https://reviews.llvm.org/D1</a>, ...). There is an option in the mips backend that aims at disabling the odd F registers, so 32bit float values only end up in F0, <a href="https://reviews.llvm.org/F2" class="">https://reviews.llvm.org/F2</a>, <a href="https://reviews.llvm.org/F4" class="">https://reviews.llvm.org/F4</a>, ... In this case it is actually expected that the register allocator still assigns the D0-D15 as usual even though the would indirectly use <a href="https://reviews.llvm.org/F1,https://reviews.llvm.org/F3" class="">https://reviews.llvm.org/F1,https://reviews.llvm.org/F3</a>,...<br class=""><br class="">Is there another way to handle this in the mips target?<br class=""><br class=""><br class="">Repository:<br class=""> rL LLVM<br class=""><br class=""><a href="https://reviews.llvm.org/D26648" class="">https://reviews.llvm.org/D26648</a><br class=""><br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>