<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 18, 2015, at 6:47 AM, JF Bastien <<a href="mailto:jfb@google.com" class="">jfb@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Optima-Regular; font-size: 18px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">We foresee having an infinite number of locals per function, but we plan to pre-color them so that locals whose lifetimes don't interfere can be merged. We can get clever and do this in an interesting order.</div></div></blockquote></div><br class=""><div class="">The NVPTX target does this with the existing register allocator by defining 800 physical registers of each type. It means you have to deal with unwanted spill code for those programs that exhaust the 800 registers.</div><div class=""><br class=""></div><div class="">The greedy register allocator doesn’t scale too well along that axis IMO. I think you get something like O(#vregs x #colors-used) behavior. It’s really designed to handle a small, fixed number of physical registers.</div><div class=""><br class=""></div><div class="">Matthias, Quentin: How well do the SSA-based register allocator algorithms work with infinite colors available?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">/jakob</div></body></html>