<div dir="ltr">So, both AVR and RISC-V are fairly register-rich with usually 32. RV32E only has 16, but that's still a lot better than i386. If you use a lot of 16 bit integers then AVR also only has effectively 16 registers (or a more with a mix of 8 and 16 bit variables). 32 bit integers should be rare in AVR code, but soft float/double variables are common in Arduino code (both are implemented as 32 bits), so you only have room for 8 of those.<div><br></div><div>RISC-V doesn't have any hard constraints on something that *must* go in a certain register, except the usual argument passing/return convention. There is a an advantage to allocating both the data src/dst register and the pointer base register for a load or store from x8-x15 (s0-1,a0-5) as much as possible as this allows the assembler to use a two byte instruction instead of a four byte instruction.</div><div><br></div><div>I haven't look at AVR in detail for a while, but I seem to recall the top six registers make up three 16 bit pointer registers X,Y,Z. Any of them can be used for (C language) *p, *--p, *p++, only Y&Z can be used for p->foo, and only Z can be used for computed jumps (including function link register) or loading constants from program memory. Also the various multiply instructions take their 8 bit operands from any registers but always produce the 16 bit result in r1:r0. Annoying but nowhere near as bad as i386 as r0 and r1 are not used for anything else. The usual ABI makes r0 a clobber-at-will temp. r1 is supposed to be "always zero", so you need to CLR it after retrieving (or ignoring) the high bits of a multiply result.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 21, 2017 at 3:44 AM, Leslie Zhai 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">Hi Jakob,<br>
<br>
Thanks for your kind response!<br>
<br>
My usecase is for AVR and RISCV targets, and I just want to learn and practice HEA in RA, thanks for your sharing.<br>
<br>
<br>
在 2017年12月21日 01:25, Jakob Stoklund Olesen 写道:<span class="im HOEnZb"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Dec 18, 2017, at 19:03, Leslie Zhai <<a href="mailto:lesliezhai@llvm.org.cn" target="_blank">lesliezhai@llvm.org.cn</a> <mailto:<a href="mailto:lesliezhai@llvm.org.cn" target="_blank">lesliezhai@llvm.org.cn</a><wbr>>> wrote:<br>
</blockquote>
<br>
Hi Leslie,<br>
<br>
As others have pointed out, the notion that register allocation is isomorphic to graph coloring is poppycock. There are other important aspects, in particular the placement of spill/fill/copy instructions. The importance of graph coloring relative to spill code placement depends on how many registers you have available. If you are generating code for 32-bit x86 which has only 6-7 general purpose registers, you will have so much spill code and short live ranges that graph coloring doesn’t matter much at all. On the other hand, if you have 32 registers like Chaitin did, you have much less spilling in typical code, and the graph coloring aspect becomes important.<br>
<br>
Early compilers would keep each local variable in a stack slot, and the register allocation optimization would literally allocate a whole local variable to a register. The C “register” keyword makes sense in that context. Later improvements like copy coalescing and live range splitting meant that multiple local variables could use the same register and a variable could live in different places at different times. It is sometimes useful to take this development to its logical extreme and look at register allocation as a caching problem: The register allocator’s job is to make sure that values are available to the instructions the need them, using the registers as a cache to get the values there in the most efficient way possible.<br>
<br>
    Guo, J., Garzarán, M. J., & Padua, D. (2004). The Power of<br>
    Belady’s Algorithm in Register Allocation for Long Basic Blocks.<br>
    In Languages and Compilers for Parallel Computing (Vol. 2958, pp.<br>
    374–389). Berlin, Heidelberg: Springer Berlin Heidelberg.<br>
    <a href="http://doi.org/10.1007/978-3-540-24644-2_24" rel="noreferrer" target="_blank">http://doi.org/10.1007/978-3-5<wbr>40-24644-2_24</a><br>
<br>
    Braun, M., & Hack, S. (2009). Register spilling and live-range<br>
    splitting for SSA-form programs. International Conference on<br>
    Compiler Construction.<br>
<br>
<br>
When you look at register allocation that way, the graph coloring aspect almost disappears. The optimum approach is probably somewhere in the middle.<br>
<br>
A third important aspect is register constraints on individual instructions. Sometimes you almost need a little constraint solver just to figure out a valid register assignment for a single instruction. Preston Briggs dealt with this in his thesis, but it hasn’t gotten as much attention as graph coloring since.<br>
<br>
    Pereira, F. Q., & Palsberg, J. (2008). Register allocation by<br>
    puzzle solving.<br>
<br>
<br>
Regards,<br>
/jakob<br>
<br>
</blockquote>
<br></span><div class="HOEnZb"><div class="h5">
-- <br>
Regards,<br>
Leslie Zhai - <a href="https://reviews.llvm.org/p/xiangzhai/" rel="noreferrer" target="_blank">https://reviews.llvm.org/p/xia<wbr>ngzhai/</a><br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>