<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 Nov 19, 2015, at 5:57 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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=""><div class="gmail_quote"><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;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class="">- Shared code path for fast and good instruction selection.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">But then I'm not sure starting here.</div><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class="">- IR that represents ISA concepts better.<br class="">- More flexible instruction selector.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Some definitions here would be good.</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">For IR that represents ISA concepts better, this is in opposition to SDISel or LLVM IR. In other words, the target should be able to insert target specific code (e.g., instruction, physical register) at anytime without needing some extra crust to express that (e.g., intrinsic or custom SDNode).</div><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm not sure that this represents the concepts any better. Basically it means that you have less and easier target independent handling, I'm unconvinced this is that useful. Perhaps an example might help :)</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">I don’t have an example off hand, but basically, any time we have to create a custom SDNode, it is useless.</div><div class="">Another thing, that I didn’t call out before because it is a strong statement and I don’t want to commit on that for now, is that we can have a better estimate for register pressure and thing like choosing addressing mode, since we are at a much lower level and that we can directly emit the proper memory operation or look at the actual register classes.</div><div class=""><br class=""></div><div class="">Those are the kind of opportunities that I envision by moving to MachineInstr level.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I guess it'll depend on how we construct the generic MIR I guess.  I'm not seeing it, but I'll hope for some magic :)</div><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;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class="">- Easier to maintain/understand framework, in particular legalization.<br class="">- Self contained machine representation, no back links to LLVM IR.<br class="">- No change to LLVM IR.<br class=""><font color="#5856d6" class=""><br class=""></font></div></div></blockquote><div class=""><br class=""></div><div class="">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></div></div></blockquote><div class=""><br class=""></div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">Agree.</div><div class="">For now, the assumptions are there are no illegal types, just illegal pair of operation and type. But yeah, we may need to refine when we get to the legalization.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Also things like canonicalization, etc. Just something to think about.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Yeah, just mentioned canonicalization in my previous paragraph and the bottom line is that I don’t think canonicalization should be required for correctness.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Well, I mean things like "target A wants op * 2, target B wants op << 2" as far as canonicalization. I'm meaning it from a "how we look at code generation level", nothing more. I'm also not too fussed here. We'll see how it comes out.</div><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;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Suggestion welcome :).</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah. First suggestion: Let's leave off the r ;)</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Gene.ic :P</div></div></div></blockquote><div class=""><br class=""></div><div class="">Hahahahahaha.</div><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class="">Which means that it should be serializable and testable in isolation yes?</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">Partly. The lowering of the body of the function will be generic, but the ABI lowering will be target specific and unless we create some kind of fake target, the tests need to be bound to one target.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That's reasonable.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">The fake target or be bound to one target?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Bound to one target if necessary. I like that we have some code generation tests that are "every target can handle this", but others are "let's see what we get on target X with this input". Both are valuable, but I don't see a need to construct up a fake target for anything.</div></div></div></div></blockquote><div><br class=""></div>Agreed!</div><div><br class=""></div><div>Thanks Eric!</div><div>Q.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">-eric </div><div class=""><br class=""></div><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;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><font color="#12c00e" class=""></font>* Design Decisions *<br class=""><font color="#12c00e" class=""><br class=""></font>- The IRTranslator is a final class. Its purpose is to move away from LLVM IR to MachineInstr world <b class="">[final]</b>.<br class="">- Lower the ABI as part of the translation process <b class="">[final]</b>.<br class=""><font color="#12c00e" class=""><br class=""></font>* Design Questions the Prototype Addresses at the End of M1 *<br class=""><font color="#12c00e" class=""><br class=""></font>- Handling of aggregate types during the translation.<br class="">- Lowering of switches.<br class="">- What about Module pass for Machine pass?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Could you elaborate a bit more here?</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">I have quickly mentioned in my reply to Marcello why this may be interesting. Let me rephrase my answer here.</div><div class="">Basically, we would like to have the MachineInstr to be self contained, i.e., get rid of those back links to LLVM IR. This implies that we would need to lower globals (maybe directly to MC) as part of the translation process. Globals are not attached to function but module, therefore it seems to make sense to introduce a concept of MachineModulePass.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">*nod* I'd like to do something about the AsmPrinter anyhow.</div><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class="">- Introduce new APIs to have a clearer separation between:<br class=""> <span class=""> </span>- Legalization (setOperationAction, etc.)<br class=""> <span class=""> </span>- Cost/Combine related (isXXXFree, etc.)<br class=""> <span class=""> </span>- Lowering related (LowerFormal, etc.)<br class="">- What is the contract with the backends? Is it still “should be able to select any valid LLVM IR”?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Probably :) </div><div class=""><br class=""></div><div class="">As far as the prototype I think you also need to address a few additional things:</div><div class=""><br class=""></div><div class="">a) Calls</div><div class=""> 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></div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">Yes, lowering of calls is definitely going to be evaluated in the prototype for this first milestone and the "lowering related” stuff was about that :).</div><div class="">(You’re good at deciphering messages ;)).</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I try. Anyhow, glad to hear about calls.</div><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">b) Testing</div><div class=""> 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></div></div></div></blockquote><div class=""><br class=""></div></div></div></div></blockquote></div></div></div></blockquote><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> </span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> </span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">* Design Decisions *</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- The IRTranslator is a final class. Its purpose is to move away from LLVM IR to MachineInstr world [final].</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- Lower the ABI as part of the translation process [final].</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">* Design Questions the Prototype Addresses at the End of M1 *</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- Handling of aggregate types during the translation.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- Lowering of switches.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- What about Module pass for Machine pass?</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Could you elaborate a bit more here?</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">I have quickly mentioned in my reply to Marcello why this may be interesting. Let me rephrase my answer here.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Basically, we would like to have the MachineInstr to be self contained, i.e., get rid of those back links to LLVM IR. This implies that we would need to lower globals (maybe directly to MC) as part of the translation process. Globals are not attached to function but module, therefore it seems to make sense to introduce a concept of MachineModulePass.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">*nod* I'd like to do something about the AsmPrinter anyhow.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> </span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> </span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- Introduce new APIs to have a clearer separation between:</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> <span class="Apple-converted-space"> </span>- Legalization (setOperationAction, etc.)</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> <span class="Apple-converted-space"> </span>- Cost/Combine related (isXXXFree, etc.)</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> <span class="Apple-converted-space"> </span>- Lowering related (LowerFormal, etc.)</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">- What is the contract with the backends? Is it still “should be able to select any valid LLVM IR”?</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Probably :) </span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">As far as the prototype I think you also need to address a few additional things:</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">a) Calls</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> 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.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Yes, lowering of calls is definitely going to be evaluated in the prototype for this first milestone and the "lowering related” stuff was about that :).</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">(You’re good at deciphering messages ;)).</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">I try. Anyhow, glad to hear about calls.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> </span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">b) Testing</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""> 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.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Honestly I haven’t used the MIR testing infrastructure yet, but yes my impression was it is not really… mature. I would love to have some serialization mechanism for the MI that really work so that we can write those testcases more easily.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">As for now, I haven’t looked into it, so I cannot share any ideas. I’ve discussed a bit with Matthias and he thinks that we might not be that far away from having MIR testing useable modulo bug fixes.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">It would be helpful if you could file PR on the cases where MIR was not working for you so that we can look into it at some point.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">My hope is that someone could look into it before we actually need a proper MI testing in place.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">(Hidden message: If you are willing to work on the MIR testing or any other mechanism that would allow us to do MI serialization deserialization, please come forward, we need you!! :D)</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Indeed, for the translation part the MIR testing is not critical since we do have the LLVM IR around.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Then, if we get rid of the LLVM IR back links, serialization should become easier and maybe MIR testing could be leverage. That being said, it may be possible that we need to start that from scratch, while taking into account what we learnt from the MIR testing.</span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class=""><br class=""></span></font></div><div class=""><font face="Helvetica" class=""><span style="font-size: 12px;" class="">Pretty much agree with this. I didn't file a bug because I wasn't sure what to say other than "this serialization wasn't useful for making test cases". Maybe you'll find it more so and we can get some best practices out of it.</span></font></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class="">Honestly I haven’t used the MIR testing infrastructure yet, but yes my impression was it is not really… mature. I would love to have some serialization mechanism for the MI that really work so that we can write those testcases more easily.</div><div class="">As for now, I haven’t looked into it, so I cannot share any ideas. I’ve discussed a bit with Matthias and he thinks that we might not be that far away from having MIR testing useable modulo bug fixes.</div><div class=""><br class=""></div><div class="">It would be helpful if you could file PR on the cases where MIR was not working for you so that we can look into it at some point.</div><div class=""><br class=""></div><div class="">My hope is that someone could look into it before we actually need a proper MI testing in place.</div><div class=""><br class=""></div><div class="">(<b class="">Hidden message:</b><span class=""> </span>If you are willing to work on the MIR testing or any other mechanism that would allow us to do MI serialization deserialization, please come forward, we need you!! :D)</div><div class=""><br class=""></div><div class="">Indeed, for the translation part the MIR testing is not critical since we do have the LLVM IR around.</div><div class="">Then, if we get rid of the LLVM IR back links, serialization should become easier and maybe MIR testing could be leverage. That being said, it may be possible that we need to start that from scratch, while taking into account what we learnt from the MIR testing.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Pretty much agree with this. I didn't file a bug because I wasn't sure what to say other than "this serialization wasn't useful for making test cases". Maybe you'll find it more so and we can get some best practices out of it.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Fingers crossed!</div><div class=""><br class=""></div><div class="">Thanks for the additional feedback, I think it really helps to call all that out!</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Q.</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">-eric</div><div class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Thanks for the feedbacks,</div><div class="">-Quentin</div></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-eric</div></div></div></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>