<div class="gmail_quote"><div>Hi Viktor,</div><div><br></div><div>I think this is a great idea overall!  This problem is something that has <i>almost</i> turned me away from LLVM several times now.  </div><div><br></div><div>
I'm by no means an influential member of the community (and hence have no real say in GSoC projects), but I do have a few comments.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I plan to implement a two-pass (almost) linear code generator<br>
specifically for x86-64 that<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
 - performs analyses (e.g. live-range analysis) on LLVM-IR in the<br>
   first pass and<br></blockquote><div><br></div><div>I assume this is for collecting information for register allocation?  For fast code generation, I would go with a local, bottom-up, linear register allocator, which shouldn't require an explicit live-range analysis pass.  It only needs to know liveness information within a single block (mostly), which should be easier and faster to compute on-demand instead of in an analysis pass.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
 - then generates x86-64 instructions directly from IR in a second<br>
   pass that writes to the executable memory (e.g. in<br>
   X86CodeEmitter.cpp),<br></blockquote><div><br></div><div>It sounds as if you are intending on mostly hand-writing the code generation part.  If this is the case, I would suggest that it would be significantly more valuable to generate it from the *.td files instead.  That way, it should be a lot easier to port to other architectures.</div>
<div><br></div><div>Sincerely,</div><div>Joshua</div></div>