<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 class="">Hi,</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 9, 2015, at 1:38 PM, David Given &lt;<a href="mailto:dg@cowlark.com" class="">dg@cowlark.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">Hello,<br class=""><br class="">I'm interested in the possibility of using libfirm as a compiler for a<br class="">CPU architecture I'm working with. I have a few questions.<br class=""><br class="">Firstly, though, playing with the latest code from git, I see that<br class="">TEMPLATE is broken:<br class=""><br class="">$ cat test.c<br class="">int add(int a, int b, int c) { return a+b+c; }<br class=""><br class="">$ build/debug/cparser -S test.c -bisa=TEMPLATE<br class="">Segmentation fault<br class=""><br class="">(Would I be better off working against 1.21? If so, where do I get it?<br class="">The download link just points at the git repository.)<br class=""></div></blockquote><div>You should definitely work against the git version, 1.21 is quiet old by now. Unfortunately the TEMPLATE backend is not a tested by our buildbots at&nbsp;<a href="http://buildbot.info.uni-karlsruhe.de" class="">http://buildbot.info.uni-karlsruhe.de</a>&nbsp;so it breaks from time to time. Anyway I have fixed it enough to work with your example again. In general I’d recommend looking at the sparc and ia32 backends which are both fully functional.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">Anyway, my questions:<br class=""><br class="">a) How well does the code generator handle situations where there are<br class="">multiple ways to lower trees of nodes into instructions? For example, my<br class="">CPU architecture has both 2op and 3op forms of some intructions; 2op<br class="">forms are encoded as 16-bit instructions, the 3op forms as 32-bit.<br class="">However, 2op instructions can only use a limited set of registers. 3op<br class="">instructions can use all registers. So, deciding whether to pick a 2op<br class="">or a 3op instruction is non-trivial, as it can have a major effect on<br class="">the other instructions in the block.<br class=""></div></blockquote><div>Our backends usually follow this pattern:</div><div>1. Select target specific nodes</div><div>2. Schedule the nodes</div><div>3. Allocate registers</div><div>4. Peephole Optimizations</div><div>5. Emit assembly</div><div><br class=""></div><div>The first step produces nodes with register requirements on each input/output but can’t know the final registers yet so you cannot select between 2- and 3-address variants yet. What I would recommend here is using 3 address operations and setting a should_be_same register requirement, that way the allocator tries to assign the same register to respective inputs/outputs where possible. In step 4 you can then change the 3op forms to 2op form in the cases where the register allocator succeeded in fulfilling the constraint.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">b) Can I have overlapping register classes? (My registers have three<br class="">different orthogonal properties which I might want to select for.)<br class=""></div></blockquote><div>There is no support for aliasing registers, you can limit node inputs/outputs to a subset of a register class. You have to be able to freely copy between any register in a class however. I’m not completely sure I understand your requirements, so not sure whether you can model this in libfirm.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">c) Instructions with side effects? e.g. post or pre increment. Is this<br class="">just a matter of writing brute force code in *_transform.c to see if I<br class="">have the appropriate graph? I notice that the existing backends don't<br class="">appear to generate these instructions. (My most complicated instruction<br class="">is a<br class="">add-constant-to-register-then-compare-with-another-constant-and-compare-and-branch,<br class="">all in a single 32-bit instruction. It would be awesome to be able to<br class="">support this, but as the possible branch displacement is very small it's<br class="">probably hard. I assume that Firm doesn't track instruction positions.)<br class=""></div></blockquote><div>Yes this a matter of writing rules in *_transform.c, things usually get a bit tricky when your pattern have multiple roots but there are certainly some more complicated rules already like folding a load,add,store sequence to a single add with load-modify-store addressing mode on ia32.</div><div><br class=""></div><div>Greetings</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Matthias</div><div><br class=""></div></div><br class=""></body></html>