<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why not do it the other way around?<br>Mark Y as reserved, and then at the end of the function if there was exactly one spill then put that variable in Y instead.<br>If there were no spills then you lost nothing by reserving Y. If there were more than one then you need Y for this stack adjustment. So exactly one spill is the only case where you lost anything by reserving Y.<br>Which is probably pretty rare, to be honest.</blockquote><div><br></div><div>This is definitely an interesting idea. I think this would be doable, but it would be a little dirtier than I'd like. We'd probably need to add a custom pass, and we'd also need to persist some spilling information on a TargetMachineFunction.</div><div><br></div><div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">This is what most llvm CPU targets do:<br>- Perform register allocation with all registers available<br>- PrologEpilogInsertion will determine the final positions for the spill/reload stack slots. If we require additional instructions/registers to actually compute the addresses for the spills/reload then we use vregs for that. [1]<br>- doScavengeFrameVirtualRegs() will use a RegisterScavenger instance to allocate the vregs: If there is a free register around it is used; Otherwise we do an emergency spill around the vreg lifetime. Targets have to ensure they reserved an emergency spillslot that can be accessed without additional registers in advance if there is a possibility that we need it.<br>If I understand you correct that strategy does not work on AVR somehow? Then you are probably out of luck and need to extend llvms CodeGen with new strategies.</blockquote><div><br></div><div>That sounds like a very similar situation to what I have, but I think that you're right in that we would not be able to guarantee a free emergency spillslot because we'd need SP in the Y register in order to store the current value in the Y register, which is impossible.</div></div><div><br></div><div>I think I can see three different options</div><div><br></div><div><ol><li>Implement Bruce's idea of always reserving the Y register and converting a spill (if we have one) to use it so that we do not waste a register<br></li><ul><li>Upsides</li><ul><li>Works for all register allocators at all optimisation levels</li><li>Does not change behaviour for any other targets</li></ul><li>Downsides</li><ul><li>A small amount of support code required</li></ul></ul><li>Teach the register allocator to check reserved registers after performing the first spill (or maybe at the end of allocation of a function) and see if any more registers have been reserved. It could then use similar code to the GitHub PR I posted above to unassign any newly-reserved registers and rewind back.<br></li><ul><li>Upsides</li><ul><li>Will work for all targets</li><li>Is the most general solution</li></ul><li>Downsides</li><ul><li>More corner cases the register allocator is handling</li></ul></ul><li>Subclass the register allocators specifically for AVR and add the functionality to a register allocator specifically for AVR<br></li><ul><li>Upsides</li><ul><li>All code required self-contained in one file</li></ul><li>Downsides</li><ul><li>Need to add subclasses for all register allocators</li><li>No other target subclasses a register allocator</li></ul></ul></ol>Thoughts welcome (and wanted)!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 2, 2017 at 8:23 AM, Matthias Braun <span dir="ltr"><<a href="mailto:mbraun@apple.com" target="_blank">mbraun@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Apr 30, 2017, at 8:27 PM, Dylan McKay via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-7078300984915394081Apple-interchange-newline"><div><div dir="ltr">Hey all,<div><br></div><div>I'm attempting to rewrite something that the AVR backend used to support (through an extremely dirty hack that was reverted before the upstreaming of the target).</div><div><br></div><div>The removal of the hack can be seen on GitHub</div><div><br></div><div><a href="https://github.com/avr-llvm/llvm/pull/226/files" target="_blank">https://github.com/avr-llvm/<wbr>llvm/pull/226/files</a><br></div><div><br></div><div>On the AVR architecture, the stack pointer is not in a standard register, but rather it is a special register which can only be accessed via I/O instructions. In order to implement stack spilling/restoring we need to adjust the stack pointer, which is a problem because we need the value of SP to be in a general purpose register for us to perform arithmetic on it.</div><div><br></div><div>In AVR-GCC, a frame pointer (the 'Y' register) is reserved if there are any spills in a method. This works fine because we can easily perform arithmetic on it and then save it into the real stack pointer via IO instructions.</div><div><br></div><div>I would like to do the same for LLVM. This is tricky however, because we don't know if we need a frame pointer until we've finished register allocation and we've seen a spill.</div><div><br></div><div>In the event that we do see a spill, it is likely that the 'Y' register has already been allocated to some other variable, and so we somehow need to deallocate it and then rewind the regalloc. That is what the old hack above does.</div><div><br></div><div>Is there any way today I can deallocate a register and rewind allocation upon spilling?</div></div></div></blockquote><div><br></div></div></div><div>This is what most llvm CPU targets do:</div><div><br></div><div>- Perform register allocation with all registers available</div><div>- PrologEpilogInsertion will determine the final positions for the spill/reload stack slots. If we require additional instructions/registers to actually compute the addresses for the spills/reload then we use vregs for that. [1]</div><div>- doScavengeFrameVirtualRegs() will use a RegisterScavenger instance to allocate the vregs: If there is a free register around it is used; Otherwise we do an emergency spill around the vreg lifetime. Targets have to ensure they reserved an emergency spillslot that can be accessed without additional registers in advance if there is a possibility that we need it.</div><div><br></div><div>If I understand you correct that strategy does not work on AVR somehow? Then you are probably out of luck and need to extend llvms CodeGen with new strategies.</div><div><br></div><div>- Matthias</div><div><br></div><div>[1] There's some restrictions on how vregs may be used here, like the defs/uses must stay within the same block.</div></div></div></blockquote></div><br></div>