<div dir="ltr">That's going to be a really challenging architecture to target from LLVM, and you'll be fighting LLVM assumptions all the way, It would be a challenge for an LLVM expert, let alone an LLVM beginner.<div><br></div><div>Of course, if you succeed then you will be an expert :-)</div><div><br></div><div>Converting functions to use statically-allocated memory instead of stack memory would be a cool feature to have anywhere, and would also be almost essential on other stack-unfriendly ISAs such as 6502.</div><div><br></div><div>To do it properly, you'd want to have functions that can never be part of same call chain (i.e. never active at the same time) share memory locations. I guess the way to do that (once you've worked out the frame size for each function) would be to walk the complete program call tree and give each function's frame the next addresses after its deepest caller.</div><div><br></div><div>And then there's recursion. If a function calls itself, or a function up towards the root of the call tree, then you'll have to save and restore all the function frames between to somewhere else.</div><div><br></div><div>Re-entrancy (e.g. things called from interrupt handlers) is even nastier.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 12:41 PM, Dawid Retkiewicz via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>As a way to learn LLVM, I'm trying to write a backend for the Microchip PIC18 8-bit microcontroller.</div><div>On this device, the hardware stack is very small and is used only for storing function return addresses.</div><div>A "real" software stack implementation is not very efficient because of the limited instruction set, so for all the non-reentrant functions I've decided to use a similar solution to the one used by Microchip's own XC8 compiler, which is to simulate the stack by assigning constant memory locations to every function.</div><div>Local variables/parameters could then be accessed by using constant memory addresses. Since this microcontroller can perform most instruction directly on such addresses, this seems the most efficient way to handle the stack.</div><div><br></div><div>The issue I'm facing right now is how to resolve the stack addresses in the LLVM backend.</div><div>For instance, when calling a function, I'd like to store its parameters directly in the memory area assigned to this function.</div><div>If I understand correctly, the exact stack size (and thus the memory needed by each function) cannot be determined before the epilogue/prologue insertion pass.This means that the target memory location is not known before this step.</div><div><br></div><div>My idea is to create an operand that would hold an identifier of the target function and the memory offset, and replace this identifier with a real memory address in a pass after emit prologue/epilogue.</div><div>However, I'm not sure how to achieve such thing in TableGen, and whether it's at all possible.</div><div>I would be grateful for any tips/directions </div><div><br></div><div>Thanks,</div><div>Dawid Retkiewicz</div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>