<div dir="ltr">Hi Quentin,<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><font color="#00afcd"><br><br></font>*** Goals ***<br><font color="#12c00e"><br></font>The high level goals of the new instruction selector are:<br>- Global instruction selector.<br>- Fast instruction selector.<br></div></div></blockquote><div><br></div><div>Are these separate or the same? It reads like two instruction selectors at the moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>- Shared code path for fast and good instruction selection.<br></div></div></blockquote><div><br></div><div>But then I'm not sure starting here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>- IR that represents ISA concepts better.<br>- More flexible instruction selector.<br></div></div></blockquote><div><br></div><div>Some definitions here would be good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>- Easier to maintain/understand framework, in particular legalization.<br>- Self contained machine representation, no back links to LLVM IR.<br>- No change to LLVM IR.<br><font color="#5856d6"><br></font></div></div></blockquote><div><br></div><div>These sound great. Would be good to get the assumptions of the legalization pass written down more explicitly as you go through this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><font color="#5856d6"></font>*** Proposed Approach ***<br><font color="#12c00e"><br></font>In this section, I describe the approach I plan to pursue in the prototype and the roadmap to get there. The final design will flow out of it.<br><font color="#12c00e"><br></font>For this prototype, we purposely exclude any work to improve or use TableGen or </div></div></blockquote><div><br></div><div>I'm getting the idea that you really don't want to work on TableGen? ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>** Implications **<br><font color="#00afcd"><br></font>As part of the bring-up of the prototype, we need to extend some of the core MachineInstr-level APIs:<br>  - Need to remember FastMath flags for each MachineInstr.<br></div></div></blockquote><div><br></div><div>Not orthogonal to this proposal? I don't mind lumping it in as being able to do this is probably a good goal for the prototype at least, but it seems like being able to do this is something that could be done incrementally as a separate project?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>At the end of M1, the prototype will not be able to produce code, since we would only have the beginning of the Global ISel pipeline. Instead, we will test the IRTranslator on the generic output that is produced from the tested IR.<br></div><div><font color="#12c00e"><br></font></div></div></blockquote><div><br></div><div>So this would be targeting Generic MachineInstr? (Better name perhaps?). Which means that it should be serializable and testable in isolation yes?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><font color="#12c00e"></font>* Design Decisions *<br><font color="#12c00e"><br></font>- The IRTranslator is a final class. Its purpose is to move away from LLVM IR to MachineInstr world <b>[final]</b>.<br>- Lower the ABI as part of the translation process <b>[final]</b>.<br><font color="#12c00e"><br></font>* Design Questions the Prototype Addresses at the End of M1 *<br><font color="#12c00e"><br></font>- Handling of aggregate types during the translation.<br>- Lowering of switches.<br>- What about Module pass for Machine pass?<br></div></div></blockquote><div><br></div><div>Could you elaborate a bit more here?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>- Introduce new APIs to have a clearer separation between:<br>  - Legalization (setOperationAction, etc.)<br>  - Cost/Combine related (isXXXFree, etc.)<br>  - Lowering related (LowerFormal, etc.)<br>- What is the contract with the backends? Is it still “should be able to select any valid LLVM IR”?<br></div></div></blockquote><div><br></div><div>Probably :) </div><div><br></div><div>As far as the prototype I think you also need to address a few additional things:</div><div><br></div><div>a) Calls</div><div> Calls are probably the most important part of any new instruction selector and lowering machinery and I think that the design of the call lowering infrastructure is going to be a critical part of evaluating the prototype. You might have meant this earlier when you said Lowering related, but I wanted to make sure to call it out explicitly.</div><div><br></div><div>b) Testing</div><div> It's been covered a bit before, but being able to serialize and use for testing the various IR constructs is important. In particular, I worry about the existing MIR code as I and a few others have tried to use it for testcases and failed. I'm very interested in whatever ideas you have here, all of mine are much more invasive than I think we'd like.</div><div><br></div><div>Thanks for tackling this project and being willing to put this out there for discussion and feedback. I'm looking forward to the code and future design.</div><div><br></div><div>-eric</div><div> </div></div></div></div>