<div dir="ltr">On Thu, Apr 25, 2013 at 4:50 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dan,<br>
<div class="im"><br>
On 25 Apr 2013, at 01:01, Dan Gohman <<a href="mailto:dan433584@gmail.com">dan433584@gmail.com</a>> wrote:<br>
<br>
> The main alternative approach that's been discussed is to do FastISel to a target-independent opcode set on MachineInstrs, and then do legalization and ultimately the last phase off instruction selection proper after that. The most obvious advantage of using LLVM IR for legalization is that it's (currently) more developer-friendly. The most obvious advantage of using MachineInstrs is that they would make it easier to do low-level manipulations. Also, doing legalization on MachineInstrs would mean avoiding having LLVM-IR-level optimization passes which lower the IR, which has historically been a design goal of LLVM.<br>

<br>
</div>The approach taken in WHIRL, which has a lot of advantages, is exactly to lower the IR.  It seems strange that in the back end we have Machine* classes that correspond very closely to IR equivalents, but which don't share any code and often have subtly different interfaces.  The approach taken in WHIRL is to progressively replace machine-independent bits of the IR with machine-dependent ones, with abstract instructions being replaced with machine instructions, abstract registers with machine registers, and so on.<br>
</blockquote><div><br></div><div style>Couldn't we first lower LLVM IR to a (mostly) target-independent sequence of MachineInstrs, and then progressively lower those?  That seems to be very close to what you describe, and makes a great deal of sense to me.  The MachineInstr could model operations and types that are not legal for the current target, but passes could lower those until everything is legal and all opcodes are target-specific.</div>
<div style><br></div><div style>Targets can still lower function arguments/returns as they please.  And most of the infrastructure for this is already present (no new IR).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I would be interested to know the rationale behind the design choice to avoid this, as it seems the obvious way of designing a compiler.  The down side would be that you couldn't take any random pass that expected target-independent IR and run it, but you never actually want to do this once you've handed off to the codegen infrastructure anyway.<br>

<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div></div>