You can expect the register allocator to be a hotspot during compiling such functions where I'm assuming your basic blocks also end up having millions of variables. I've not tried this in LLVM but in other compilers I've used it certainly has been an issue.<div><br></div><div>Since you mentioned automatic code generation which is also how I ended up[1] in a similar situation I can tell you that 10,000 local variables or whatever you're attempting can usually be solved by instead making it an array of those things you were going to make individual variables.</div><div><div><br></div><div>[1] it was a protocol buffers like code generation scenario of a schema that had thousands of fields (unrelated to each other) and I had to sort of invent this arraying strategy to prevent compile times from skyrocketing, that said the compiler at the time was using an n2 register allocation algorithm.<br><br>On Saturday, August 22, 2015, Russell Wallace via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','mzolotukhin@apple.com');" target="_blank">mzolotukhin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
Several passes would have troubles with such code (namely, GVN and JumpThreading).</blockquote><div><br></div><div>Can you just choose not to run those particular passes? I suppose the big problem would be if there's a problem with the code generation and related stuff like instruction scheduling and register allocation - is that likely to be the case? </div></div></div></div>
</blockquote></div></div><br><br>-- <br>Sent from MetroMail<br>